I actually think PNVI-ae-udi is pretty good semantic model for a systems programming language, considering that it is the essentially only reasonable model on how to combine abstract pointers with low-level integer based pointers in a way that makes it work well. I am not entirely sure I would allow one-after points if I were to design a language from scratch, but I haven't made up my mind about it.
While it makes sense that you landed on PNVI-ae-udi for C because of its prior baggage, I don't see how this makes a good choice for a language without that baggage.
For one thing, I'm pretty sure systems languages don't need to combine these two ideas at all. In C there's a single pointer type and so it has both uses too bad, but in a hypothetical new language you don't need to do that and I think it would be clearer not to.
The good news is that you already listed the two separate ideas. In C you need to have a single type which embodies both contradictory ideas, but that's actually a choice, albeit one it's far too late for C to change now.
The fact that choices you made in the past can't subsequently be changed is baggage. Even if you decide tomorrow that this was a waste of your time and you should never have worked on the provenance problem, you can't have that time back. [that's an example of personal baggage, in the case of C the early choice to only have the single type for both purposes is the baggage]
