I don't know if it's quite a "flag day", but Microsoft is definitely going to make some breaking changes soon in .Net 5.0.
The particular one I'm watching for is lambda closures. Currently it's close-on-reference rather than close-on-value, even on value-type objects. This leads to some really counterintuitive behavior in certain situations.
Breaking changes are perfectly fine as long as you keep supporting legacy runtimes. That's why we have major framework versions (eg Java 7/8, .Net 4.5/5.0, etc).
Flag Day means your project is now stuck on the version of the legacy runtime of your slowest dependency to upgrade. If you have a dependency that is no longer being maintained, migrating away from it is then required.
This kind of flag days is why you still see some Java 1.4 around for some projects 8 years after it went into it EOL period! Projects on java 1.5 are relatively rare because they where easier to upgrade to later versions. (Java 1.5 introduced enum as a keyword, 1.4 assert) Java 1.6 and later did not introduce flag days like that for code. I think that the Java team has learned that flag days are very very painful for the wider ecosystem.
Something, I am personally very happy with. Because by going slower I think they have started to go faster for us end users ;) The accepted Lambda syntax and implementation was much better than the first proposals and lost nothing in expressive power. Sure it added 1.5 years before we got them, but when we got them we could actually use them right away.
In my experience code is kept longer than runtimes. The project I have worked on for the last 7 years was started on Java 1.4 and is moving in production to 1.8 next month. If we had to rewrite a significant part of the code each time a new version came out we would still be stuck on 1.5 today!
Sure Java is paying the price of decisions made 18 years ago, but that is the nature of technical debt ;) at least most of this debt was used as an investment instead of wasted.
PS. .Net is significantly younger than Java being a late 90's language instead of a early 90's one.
PS. These new keywords in java 1.4 and 1.5 did impact real world code, in one project we moved code from 1.4 to 1.5 and had to rename a package from something.enum to something.enums. Then we ended up with a crippling bug because some incompetent had used reflection to select a class on the basis of information stored in the Database, a class that enum in its name :( So a trivial change using refactor in JDeveloper let to a huge bill in emergency fixes roll backs and SLAs being missed.
Being compatible with existing code, while still evolving to the future is of real value!
The particular one I'm watching for is lambda closures. Currently it's close-on-reference rather than close-on-value, even on value-type objects. This leads to some really counterintuitive behavior in certain situations.
Breaking changes are perfectly fine as long as you keep supporting legacy runtimes. That's why we have major framework versions (eg Java 7/8, .Net 4.5/5.0, etc).