I think this is a bad, bad idea. While SemVer is not by any means perfect, the arguments you give for abandoning it are either in SemVer by design or a matter of time.

In order: 1. A 'breaking change' in SemVer is a change where the API was changed. Code that was built against a previous version will now fail to build. It does not mention behaviour in any way, only the exact contracts your software correspond with. As such, there are no 'major' or 'minor' changes. It's either a breaking change or not a breaking change. The minor versions in SemVer are for additions that don't break the API but add to it, and so do not constitute breaking changes.

2. Psychological influences are a matter of time and saturation. SemVer is more and more widely used, but the psychological element you say is mostly an artifact of the random way versioning was done before it. Over time, and with further adoption of SemVer, people will be less afraid of upgrades and in general more sensible about it. This is an effect of the improved predictability of what a bump in what version number implies.

3. Code is supposed to linger for a decent time in <1.0.0. Version 1.0.0 is the first version that has a defined API that is guaranteed to be there until 2.0.0, so software naturally takes a long time to stabilize enough for that to be possible.

[1] Since SemVer only demands a bump in the major version if the actual API changes, most packages won't go through a lot of them. In general, a product that has reached some level of maturity will have a stable API, for the benefit of the programmers and the consumers alike.

My biggest gripe with your versioning system, however, is that it's not cross-compatible with SemVer. You're introducing an alternative that does not work in the same way, is not easily distinguishable from SemVer, but can break my code after an upgrade. What if I think your package works with SemVer, and so upgrade to a new minor version thinking it's fine and the API wasn't broken? Suddenly, I've got a version of your package that does break, and I've got a lot of work to undo the upgrade. At worst, I don't notice the breaking until it's already running in production and Bad Stuff Happens.

I'm fine with criticizing Semantic Versioning, and you're free to find your own alternatives, but they should be cross-compatible with SemVer or very easily distinguishable. Using the same syntax to signify a completely different semantic is a recipe for disaster.