Im not surprized by this. The Angular 1.x codebase is significantly different to the 2x architecture (which is still what modern angular runs on). Also back then the ecosysten and tooling wasnt as stable as it is now. Migrating from 1.x was pretty much a big rewrite if you where doing anything remotely interesting.

I recently upgraded multiple repositories from 11 to 14 (all with ngrx/store) with no issues to speak of.

Are you sure you used the upgrade scripts or did you just yolo style increase the angular version in the package.json to latest?

Yes.... Just one example if you are curious. At some point NGCC broke parallel builds. https://github.com/angular/angular/issues/38875#issuecomment...

The project I'm upgrading is a library used by other downstream projects. My goal was to release a working version of the library for each Angular release. However, I could never resolve this particular issue and just had to skip that version of Angular.

Another common problem I ran into - dependencies that support, for example, ng11 and ng14 but not ng12 or ng13. So your options are to skip that version of Angular, try to replace or remove the dependency, or beg the author to add support for a version of Angular that is years out of date.

And material components version 15 has a breaking change around custom themes that means either I cannot upgrade to that version, or I have to completely rewrite the entire theming functionality within my project. So yes, I can run ng update @angular/material@15 and migrate the code easily, but that doesn't mean "it just works".

To be clear, I'm not complaining about Angular, or anything else in particular here. In my case, the decisions of the original authors caused upgrading to be more difficult than it needed to be. My point is, without knowing the details of any particular project, it's easy to see how upgrading across several major versions can quickly turn into a nightmare of rewrites.