Duplicates with different restrictions or no restrictions

Long ago, this challenge was posted, with the restriction that no numbers may be used in the source code.

Recently, another challenge was posted, this time without any restrictions on the source code.

Both challenges have the same theme - the look and say numbers. However, the original challenge was very restrictive, had no input, and only required a fixed output (the first 20 look and say numbers). The new one is simply the task with no restriction, and also differs in that it is required to take inputs: both the number of iterations and the starting number.

Even without these additional differences I would expect that in many cases simply the lack of restrictions would make solutions to the restricted challenge uncompetitive in the unrestricted challenge, suggesting they are not duplicates. Is it acceptable to have both restricted and unrestricted versions of a challenge?

The recent catalogue questions seem relevant to this discussion, as they were also unrestricted versions that had plenty of restricted precursors.

For example:

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).

• I originally tossed a dupe-close vote on the new one, but after reading this, I agree with this reasoning. So, I threw the first dupe-close vote on the old one. – Mego Feb 3 '16 at 19:00