I've been thinking for a long time that our non-competing policy for newer languages (or language versions) is harmful. Just for context, we currently require all answers which require implementations that are newer than a challenge to be marked as non-competing. At the core there was a good intention behind this rule and that is to prevent people from adding a built-in to their language which solves the challenge in one byte, but I think that in 99% of cases the rule ends up hitting the wrong answers.
Some arguments for allowing all languages and versions on all challenges:
- Just empirically it seems that the vast majority of all non-competing answers on the site are either a) people wanting to give old challenges a spin with new languages, b) people encountering a bug in their language when solving a challenge and having to fix that bug before being able to solve the challenge, or c) people wanting to use well-specified, old languages which need to be (re-)implemented before they can be used. Neither of those lead to problematic answers but are disappointing or frustrating for the answerer.
- We regularly get people suggesting that sufficiently old challenges should be allowed to be reposted (the most recent example), with one of the main arguments that new languages have since been created which can't compete on the old challenge. But reposting challenges leads to all sorts of other problems, in particular what to do with old valid answers. It would be much easier if we didn't discourage people from answering old challenges.
- I believe the community has come a long way from competing for the overall shortest answer on a challenge. Most people who aren't using Jelly or 05AB1E or the like are usually competing within their own language (or maybe with languages of comparable verbosity). Adding a built-in to the language just for that challenge simply makes the language uninteresting for the problem at hand. Improving the language in a way that shortens the current problem but is also useful in general doesn't seem problematic to me (and the change will also be available to other users who might still be able to outgolf the answer). Either way, the non-competing label seems meaningless if we're not comparing the answer to solutions in other languages anyway.
- Many of our most-answered challenges (those which started out as "catalogues", i.e. the challenges for certain standard programming problems) already override the non-competing policy explicitly without any detrimental effect (and thereby becoming more useful repositories of golfed solutions for these problems in all languages, regardless of the language's age).
- Adding a built-in to solve a challenge isn't very interesting and will likely be discouraged by downvotes more than anything else, especially if someone does it repeatedly.
- The non-competing rule doesn't even reliably solve the problem it's trying to solve. While the Hello, World! challenge already allows newer languages, this answer wouldn't have been non-competing anyway (I realise this is a counterexample to my previous point, but HNQ can sometimes do that). And there are other ways to get a 1 byte or 0 byte program working before a challenge is posted.
- While we're not doing this consistently yet, we have a well supported proposal to combine trivial answers into a single CW answer. That would further reduce the incentive to add built-ins to languages unless they're generally useful.
Yes, we'll probably get the occasional answer that adds a built-in after the fact and gets a lot of undeserved votes for it, but I really don't think that this rare case outweighs all the disadvantages this policy brings with it.