The existing wording was written before the aliasing constructors were added to shared_ptr so they were not phrased in terms of the aliasing constructor. You're right that the spec can be simplified, see how it was done at https://rawgit.com/cplusplus/fundamentals-ts/v1/fundamentals-ts.html#memory.smartptr.shared.cast

I don't think removing the notes is a good idea, they're still useful.

@jwakely, the Fundamentals TS wording looks equivalent to me, so I'll gladly abandon this PR if that wording is being approved for C++17. :)

However, I do think the notes are more confusing than helpful. The existing wording is of the form

Returns (a very complicated but correct-looking construction).
Note: (A simple but obviously incorrect construction) seems equivalent, but it isn't.

This is confusing because the obviously incorrect construction does not seem equivalent at first glance, and the reader must expend a lot of brainpower to rationalize what the Standard could possibly mean by "seemingly equivalent" in this context.

The Fundamentals TS wording is of the form

Returns (a simple and correct-looking construction).
Note: (A simple but obviously incorrect construction) seems equivalent, but it isn't.

Here the note is confusing for the same reason, but the reader doesn't have to expend as much brainpower on rationalizations, because it's much more obvious that shared_ptr<T>(r, static_cast<typename shared_ptr<T>::element_type*>(r.get())) is not equivalent to shared_ptr<T>(static_cast<T*>(r.get())) and never could be.

IMO it would be significantly clearer to simply say "Returns (the simple construction)" and let the reader come up with his own simple-but-incorrect variations. The simple-and-correct variation will be right there on the page for him to compare his wrong variations against, even without a note.

I do think dynamic_pointer_cast deserves a note, but not the current note. After the wording changes, the average reader might wonder why dynamic_pointer_cast isn't defined using the same construction as the other two templates. A note to clear this up would be valuable, IMO.

It doesn't mean the incorrect version is seemingly equivalent to the complicated expression, it means it is seemingly equivalent to "please give me a shared_ptr containing the result of a static_cast" (i.e. it refers to the purpose of the function, not the implementation details)

As explained above, I don't want to lose the notes, and would rather just take the updated wording from the TS.