Thank you for the response, I’m glad to have you chiming in here!
The problems have been named in the internals list, and have been, in part, mentioned in your article. Some breakage here and there and unexpected behavior. Nothing critical from my point of view, but it happens nonetheless.
I completely agree with you on this one. Functionality that is to be removed, especially if considered to have a large enough user base still, should first be marked as deprecated. But who is to judge how large of a user base is still using a given functionality?
And what is the status of these languages today? How used are they? How many courses do you see on them? How many newbie developers ask “Should COBOL be my first language?” rather than inquiring about PHP?
On a final note - I’d like to inquire: does fixing your codebase to respect the new constructor rules really entail so much effort? Surely if you search for all instances of such behavior and have a sufficient amount of unit tests in place you could fix all of it in a day or two? I really am curious as to the nature of your application that is so brittle such a change would destroy it, and yet still incompatible with minor code alterations as to avoid this disaster.