One of the codebases I currently work on has the same kind of thing for expression trees, except with pseudo-value-semantics: instead of saying "I have a pointer that may or may not be owning," we say "I have a tree which I may or may not be responsible for cleaning up." This was originally done for convenience when referring to a subtree: user A can refer non-owningly to a subtree of a larger tree that is actually owned by user B. Both user A's and user B's "tree" objects have the same type and can be passed to the same callees.

We have differently spelled accessors for "give me an O(1) 'copy' that is a nonowning reference to this same (sub)tree" and "give me an O(n) copy that actually makes a copy of this (sub)tree and then owns it." Figuring out which to use in any given situation is an art.

I consider it a nightmare to work with!

Admittedly we don't call it a "ptr" but a whole "tree" (naming is hard!), and we have the added wrinkle of being able to confuse subtrees with whole trees... but I would be fairly adamantly against ever introducing anything even vaguely along these lines into any codebase I ever worked on. It's just a huge mass of dangling-pointer bugs waiting to happen.

I expect that the potential for dangling-pointer bugs means that the Committee won't be thrilled with your proposal either.

Significant technical issue with your spec: You give your type a constructor overload set containing

    (1) ptr(ptr) — This is invalid. I'm not sure what you meant to type.

    (2) ptr(T*) — You specify that this constructor is non-explicit, and that it creates a non-owning ptr. That's problematic because every other smart-pointer type in existence has an explicit constructor that creates an owning ptr. You should follow their lead, or else discuss in the paper why you're striking out on your own.

See also P0468r1 and P1351r0, especially the latter's section "Retain by default." (It's unfortunately very terse and doesn't explain much. Your paper should explain even better. :))

–Arthur