>> The problem now is that removing support for 'elisp' would break too
>> much.
>
> What I suggest for this particular issue is this: first be liberal
> while staying consistent (thus allowing "elisp" as Troy suggest),
> then be strict when a major release is issued (thus removing aliases
> that are problematic, not just "elisp" but others.)
>
> WDYT?  Troy, would you be able to prepare a patch for this?

My 2¢ from the peanut gallery.

Generally speaking, I’m in favor of consistency. A couple of months ago,
I stumbled over the fact that ‘elisp’ seemed to do syntax highlighting
correctly but didn’t tangle. I didn’t, at the time, work out the cause
of the problem, I just learned to use ‘emacs-lisp’ as the language name.

Looking at this thread, it seems like there are a bunch of exceptions to
the rule that the language is be the name of the mode without ‘-mode’.

Just off the top of my head, I can think of several languages supported
by multiple modes. If the rule is that the language is the mode name,
then if I use ‘extra-special-language-mode’ to edit ‘language’, do I
have to use ‘extra-special-language’ as the language name? Is that going
to seem natural? What burden does that put on the developer of
‘extra-special-language-mode’ to make tangle and other Org-mode features
work like they would for ‘language-mode’?

I wonder if it makes more sense to invent a mechanism for assigning
language synonyms that can be used throughout Org?

                                        Be seeing you,
                                          norm

P.S. Just to prove I can play devil’s advocate, I’m very conscious of
the fact that a few days ago, I invented an ‘xproc-mode’ as a vacuous
extension to ‘xml-mode’ precisely *because* I wanted to define different
org-babel-execute behavior.

--
Norman Tovey-Walsh <ndw@nwalsh.com> | Some disguised deceits
https://nwalsh.com/                 | counterfeit truth so perfectly
                                    | that not to be taken in by them
                                    | would be an error of
                                    | judgment.--La Rochefoucauld