This is a helpful model vs deprecations
I think the concept of "layers" has been beaten to death and stretched way too thin, to the point of meaningless.
With that out of the way, random thought:
Most NIPs are not nostr but protocols on top of it (nostr = NIP-01)
NIP-04 (DM/encryption scheme), NIP-44 (DM/encryption scheme, NIP-46 (remote signing), NIP-47 (wallet protocol), NIP-90 (data vending machines), etc. All different protocols built on top of Nostr.
That's why we can end up with competing NIPs implementing the same functionality, and why worse NIPs with more network effects can prevail.
E.g. Should a new client that wants to implement DMs go with NIP-04 or NIP-44?
I agree with nostr:npub1acg6thl5psv62405rljzkj8spesceyfz2c32udakc2ak0dmvfeyse9p35c that rewriting NIP-46 in a completely incompatible way was the wrong approach and it would have been better as an independent NIP that should have battled it out against NIP-46 in the market, just like NIP-44 is challenging NIP-04.
Seeing (some) NIPs as protocols, and not simply functionalities might be a good heuristic:
NIP-46 is not just "remote signing" it's "remote signing with this particular protocol", if we want to change the approach it makes sense to do it via a different NIP that needs to earn it's own and dethrone the competing protocol that provides the same functionality.
Discussion
i personally think that if you go look at my version of go-nostr
https://github.com/Hubmakerlabs/replicatr/tree/main/pkg/nostr
you will see that i am in the process of ordering the protocol by human readable concepts and far more clear than the existing shomozzle based on this stupid RFC derived number specification shit
i'm not against the numbering of the specifications, per se, so much as not having a cohesive map of the architecture of the system that keeps things related to each other
you will see as you dig through the code how i have reorganised go-nostr that the majority of the protocol fits into a set of simple concepts and some have branches on them, like envelopes, which are the nostr equivalent of API messages
i think that the protocol will advance a lot faster once people start to tie together the specification better and have an easy reference to work on
hell, after i'm finished my current assignment, i'd be very happy to write the documentation that ties everything together with lots of obsessive hyperlinks to the NIPs and even their historical state to help devs really wrap their heads around it because it really is a lot to learn and the structure is contrary to easy learning