Angular 2+ is now simply Angular. All new releases follow a naming of version X.Y.Z where X indicates breaking changes, Y non-breaking new features, and Z is bug fixes.
Version 3 is being skipped over due to poor naming of the related Angular Router lib.
http://angularjs.blogspot.com/2016/12/ok-let-me-explain-its-...
A major version bump for a module could signal a breaking change, or it could just be due to the packages it's locked to having had a breaking change
This is why keeping your dependency list as tiny as possible is imperative.
Should that be a new major version of the library?
The more nuanced answer is that it depends on your packaging system and your language runtime. If either cannot handle more than one minor version of a dependency at the same time, you need to bump a major version. The problem is that the code that uses your library might also indirectly be using that dependency, but pinned to a different major version. This means that the application is broken even though the breaking changes aren't used by your library.
To illustrate:
apple-1.0 => banana-1.0 => carrot-1.0
=> broccoli-1.0 => carrot-1.0
apple-1.1 => banana-1.1 => carrot-2.0
=> broccoli-1.3 => carrot-1.1
Even if you can juggle two dependencies of the same library, you need to make sure there wouldn't be any logic changes that would break the system or even corrupt data (!).
Anyway, it's simpler to be conservative and bump the major version. Yes, that can be a pain. But, again, it's good to keep your dependency list small or at least very boring to keep that pain to a minimum.
The spec only specifies one of those directions, you're free to bump the major version for any change if you feel like it. Doing so would make your versioning scheme much less useful, but it's not actually breaking the semver rules.