Angular 2 and ecosystem: dislikes?

Ok, so Angular 2 generates a good amount of attention with lots of great things touted about it.  That is fine but what matters to me is whether it is like the medications advertised on TV - "Cures you <insert condition here>" but in tiny print has "side effects of nausea, vomiting and sometimes death".  Angular is still pretty new to me - typically I work mostly on back-end Java development. I'm not doing new Angular coding right this second but for a couple months I have been doing automated builds for Angular 2 projects and just started to work on converting some Angular 2 projects from Gulp based to mainly just NPM with Webpack2 which is resulting in some coding along the way.

Ok, so let me start off by saying that I don't think Angular 2 will have 'death' as a side effect.  Maybe headaches though.

My list of issues - some not directly Angular issues but related in various ways through tooling or general ecosystem.

• Documentation is poor.  I find myself asking questions like 'what about this or that' and official docs for what seems like most stuff in the NPN repository don't have the answers.  I waste too much time looking for answers at Stackoverflow or elsewhere for usage/API questions rather than working on the actual functionality. This isn't an Angular (2) specific issue but they didn't improve things.
• Searching for Angular 2 documentation, etc results in many links to Angular 1 stuff or to items which a beginner can't easily identify as Angular 1 or 2.  Just "Angular" everywhere. I wish that those blogging or writing examples, documentation, etc would consistently include a version in the content or at least a date when something was written so there is a better chance of figuring it out.  I'll admit that I don't always think about this aspect either until I'm on the receiving end of new technology but when breaking changes are very common this is more important.
• Seed projects drive me a bit crazy when they use beta software.  As of the date I am writing this (3/5/17), what appears to be a common seed project here is using webpack 2.1.0-beta.27. I have never worked where we would rely on beta software - especially well after non-beta software was available. I spent some time already looking into the non-beta webpack 2 and I see how the particular seed we used pushed the developers into using the beta initially.  I just wish that they would put time into converting to non-beta software even if it will take some effort.  It seems odd and unwise to expect further beta updates after a stable release so good luck with bug fixes or security issues. And just so no one thinks I am talking about just Webpack2, in this instance rxjs 5.0.0-beta.12 is also in this seed.
• NPM is so slow I feel like my hair will be totally grey before most 'npm install' processes finish. I did see there is at least one attempt at an alternative (Yarn) but I had problems with an app with just a moderate number of dependencies and it was still pretty slow for me. By version # terms, Yarn is still really young and I hope it makes major improvements. 
• NPM version? I've yet to see any nice documentation stating when/where particular NPM versions should be used. I've read some information listing some of the differences but nothing really saying 'hey, version 4 is where you should be now because..' or making it clear what the impact is of using various versions in different contexts.  Is it s difference of works versus not or simply efficiency differences? Does it depend on other considerations?
• Many 3rd party libraries are not using semantic versioning yet.  If people are creating apps/libs and passing them on to you for further work before deploying to production many times the build is dysfunctional by time I even try the build process. To many packages making breaking changes with no way of knowing by the version number. An example issue with ng2-bootstrap can be viewed here.  I think the main contributor to the issue is the extensive/default use of "^' and '~' to modify the process of selecting compatible dependency versions.  The default should be to NOT use them(^ or ~) in my opinion. It is a huge time waster trying to get a build working which was just handed to you that won't build because 'some' component got upgraded to an incompatible version which must be tracked down. [edit 2017/04/20] You have probably heard of Perl being referred to as a "write once" language - I sometimes think about Angular as a "build once" technology since each and every build of the same code has the potential to fail.
• Private NPM registry?  I found the 'blessed way' of handling this to be underwhelming. If you search for other free/open source options you will likely end up at Sinopia which is a dead project last I checked this issue. Note that nothing at the Sinopia link indicates it isn't maintained.  I would recommend Verdaccio at this moment. I find it crazy that you must expend a good amount of time just to figure out a reasonable open source private registry solution.  There are several non-open source solutions available.
• I've run into a number of odd and possibly random issues during 'npm install'. At this point, I'm trying to keep up with npm updates hoping to reduce the number of days where repeatable builds seem impossible.  Tools or infrastructure - who knows?
• Module systems - CommonJS vs AMD vs ES6 vs .... And people complain about the complexity of languages such as C++..  
• Typescript and integrating 3rd party JS based modules - I'm still working through a situation where a 3rd party module has only a single anonymous function exported and there is no definition file. This is another productivity killer. This may be more of an experience issue (lack of on my part related to Typescript) than a true technical issue but googling for "best solutions" is slow in this case.
• Throw in some technology such as an API generator targeting Angular 2 and other technology such as an API proxy and you get some unwanted complexity.  What was initially a quick (and good) way to stand up simple applications turns into something much higher in complexity.  How how I can't say. 
• Arg.  Renames of packages and/or packages of similar names make thinks difficult to sort out when looking for useful components and/or tying to use them.  Too much change and little maturity.

[Edit 2017/04/20 - feeling the need to add some positives to my analysis] 

+ It sounds like Angular 4 is a step toward better versioning (semantically speaking). I don't know that it is a total fix in itself since there are still many libraries/frameworks that need to fall in line regarding versioning.  

+ The dependency injection in Angular has been somewhat useful.  

+ The overall "feeling" of development isn't too bad - given enough time and maturity it may be "very good or great".

So should you dump your applications / user interfaces that are rooted in JEE type technology? I don't think so. At least not yet. It is probably worth keeping an eye on technology such as this.  I would certainly evaluate the risk for the type of use you expect along with the productivity differences between this and whatever you were doing.

Thanks for reading!
May Jesus bless your day!

Scott