If your sole definition of "being crappy" is readability/maintainability,

That was not my sole definition.

What is the point in moving to a new version of a language, if the libraries you need to do anything productive are written in the old version and the new compiler runs them half as fast as the old one?

What is the purpose of re-writing a language if it has to be bug compatible with the old one?

What is gained by writing the new version -- adding all the new features and facilities; cleaning out all the old anomalies, disorthogonalities, historical detritus and cruft -- if the libraries required to make productive use of it, not only cannot take advantage of those f&fs, but also force you to add back support for everything that you were trying to get rid of? (Who would buy a Bugatti Veron if they were required to employ a man with a flag to walk in front?)

I never stated that maintainability, readability would be an a priori requirement

No. I did. Without maintainability of the generated code, the migrated code can never evolve.

Everyone using it will be stuck in transition, requiring two sets of tools (+the translator); two sets of skills for tracking down bugs -- do they originate in the pre-translated code or are the introduced by the translator; or are they in the in the new compiler/VM. The idea is a nonsense.

a quick, low/no cost migration path.

There is no purpose in migrating if all you get from the exercise is what you have now without it.

Is is cost for no benefit. A make-work exercise.

Technicians are responsible for the first 1% of the bootstrap process

That sounds an awful lot like you just agreed with me, and then dismissed it without reason.

Without the first layer of bricks, the wall doesn't get built. But it goes (metaphorically) deeper than that. You need foundations.

And it isn't business managers, or marketeers, or HR or money men that go out looking and downloading and appraising and providing feedback to new languages. It is technicians. If language development had been left to business managers, we'd either all still be using COBOL; or every IT business, finance house, government body and conglomerate would be using its own proprietary languages for commercial advantage and/or security reasoning.

Technicians may need the sign off from business and money guys to adopt new languages for production -- and that is probably a good thing :) -- but they need a very clear and undeniable technical & business case before they will ever get that sign off.

And the technical case must come first; and must be sufficiently technically compelling to gain their interest in the first place. Without it capturing the hearts and minds of the technicians first. new languages are still-born.

(The rare exception are the military with things like Ada. But that is a one-off thank god.)

Well, I'm not surprised. Because you start from the wrong assumptions, then make right deductions, you still end up with the wrong conclusions.

Right back at yer.

you see a resource clash where there is none.

Not a clash, just a waste that could be redirected to better use. But it is your time and money and your decision.

Once again. Good luck.