Question: For example:

`shared_ptr<const shared_ptr<const int> > pp;`

is fairly intimidating... whereas

`const int ^ const ^ pp;`

is instantly reminiscent of the raw pointer equivalent

`const int * const * pp;`

Answer: 
On top of what the existing answers have pointed out, one reason why this is a Bad Idea(tm) is that `shared_ptr` isn't really something to be encouraged.

It is one type of smart pointer among several, and it has some critical shortcomings (it is *far* slower than any other widely used smart pointer, and using it can lead to memory leaks if you're not careful), and it is grossly overused.

What should be encouraged is the use of RAII *in general*: whether that is done through the use of various smart pointer classes (including, but certainly not limited to, `shared_ptr`), or through your own RAII wrappers around resources or by using the standard library containers is irrelevant. They key is to rely on RAII for resource management.

But a syntax such as this would elevate `shared_ptr` to some special status where it is *more* important than `std::vector`, `std::unique_ptr`, `std::weak_ptr` and all the other extremely useful examples of RAII in the standard library.

That would be misleading, and is only going to exacerbate the ridiculous over-reliance many people already have on `shared_ptr`.

I generally consider `shared_ptr` a last resort only. When possible, I prefer *any* of the other smart pointer classes, and only if none of them will do the job, do I consider using `shared_ptr`. Bjarne Stroustrup has said something similar about shared ownership in general. Ideally, your code should have stricter ownership semantics. `shared_ptr` is just there to take the last few cases where shared ownership really is the best (or least bad) option.

Another, more objective, reason, is that C++ draws a clean line between "core language" and "library". For something like `int ^` to be valid, `^` must be given special treatment in the core language, the same way that `*` is.

So `shared_ptr` would no longer be a library component, but a core language feature.

The standard committee tries to avoid that as much as possible, using the rule of thumb that anything that *can* be implemented as a library *should* be implemented as a library. And if it *can't* be implemented as a library, perhaps, instead of adding it as a core language feature, it'd be better to add something more general to the language which would allow it to be implemented as a library.

But `shared_ptr` can be implemented perfectly well as a library component. There'd be very little to gain from elevating it to the core language.
Very unlikely. C++ is already an intimidatingly complex languages and adding one more feature with potential ambiguities (XOR operator already used) + the fact that Microsoft's CLI version of C++ uses this syntax for managed references -> chances for it happening are close to zero.