It sounds like a fully compatible code is not really possible, so some
test to detect which etags/ctags program will run, with the necessary
code tailored to each of them, seems like the best COA in the long
run. It's a bit more coding, but the differences are fairly minor, so
I don't expect that to be too hard.
It's one more source of bugs, because I would personally be using only
one of the code paths on the regular basis, and the same might be true
for emacs-devel regulars who might try it out.
But below you propose a compatibility layer anyway, for the regular
expressions, right? So the danger of less testing and more bugs still
exists under that proposal, AFAIU. And the compatibility code for
using "-L -" vs just "-" is very simple, so why not put it under the
same condition as what you plan for the regexp compatibility?
But in the long run, it might be good for us to have a better level of
compatibility with 'ctags -e': less user confusion, for one thing. And
for best results, I think we should approach that compatibility from our
side (if we do at all), rather than wait for them, because older
versions of third-party software will be around for a long time, but we
can more or less be sure that Emacs comes with the latest version of etags.
Maybe I still don't understand something: how would "compatibility
with 'ctags -e'" be different from what is discussed here, including
this:
FWIW, -L plus a compatibility layer for --regex (translating
--regex-lang=abc to --regex={lang}abc) should suffice for etags-regen
for the near future.
And support for --langmap, maybe (does etags have a counterpart for it
at all?).
The equivalent of --langmap is "-l LANG", I think. (We could also
teach etags to support --langmap directly, patches welcome.)