Regarding a general policy
I don't think a general rule on restricted challenges would work very well. It depends a lot on the challenge and the restriction whether it makes a sufficient difference. Print "Hello, World!" without any numbers in your code is practically the same as Print "Hello, World!" (except for some esolangs where that restriction will likely make the task altogether impossible). On the other hand Test a number for primality with a palindromic program is probably going to lead to vastly different solutions than Test a number for primality (barring trivial solutions that put a comment character in the middle). At the same time, disallowing built-ins will often greatly change the challenge for those languages that do have a built-in for that task. And yet, I don't want to see two copies of every challenge, where one allows and one disallows built-ins, because one of them likely doesn't add anything interesting (here I generally prefer allowing built-ins and encouraging people to include built-in free alternatives in an FYI section or something).
Whether any given restriction makes any given challenge sufficiently different and/or adds anything interesting to the site should probably be left up to the close voters to decide on a case-by-case basis.
If we do decide that the a restricted challenge and an unrestricted challenge are duplicates, I'd vote for closing the restricted one, because the restriction likely distracts from the actual tasks at hand, and less is usually more. I'm generally in favour of closing old challenges as dupes of new ones, so I don't think the question of which one was posted first should factor into the decision of which one is closed.
Regarding this particular challenge
Whether or not the old one is closed, I believe the new one should remain open (following the previous paragraph). Without the restrictions and with the more general I/O specification, the new one seems like the challenge which is a) a more typical statement of this problem and b) more likely to generate answers whose techniques can be reused in future challenges (in a way, the look-and-say sequence is a simple way to showcase the shortest way to implement run-length encoding in a language).
As for the old one, I don't think the restriction is particularly interesting since the core algorithm doesn't depend on number literals at all (barring for loops in some languages, that can probably be easily work around). Comparing my CJam answers to both challenges, the differences are more due to the hardcoded inputs and the fact that all steps need to be printed. The core algorithm remains {...se`}* which is entirely unaffected by the restriction:
X{NX$se`}J*
q~{se`}*
So I'd like to see the new one reopened and the old one closed subsequently, but I'm not going to throw a mod hammer onto either (although I might do so if there are already a few votes from other users).
