I see your point but, IMHO, optional<T&> is too different from normal references to attempt to draw this association. After all, optional<T&> is an object in the sense it has internal state and you can take its address while T& is not (one may call it an alias of an object). It is therefore logical that optional<T&>::operator= operates on the object (i.e. on the optional contents) and hypothetical T&::operator= operates on the referred object.

...

Note that if you store a normal reference to int as class member, you already have to write your assignment yourself. changing a normal reference to an optional reference should not come as something irregular.

Again, I tend to see optional<T&> as an object, with no apparent reason why it cannot be assigned to.

I understand (I think) your point of view. Let me clarify one thing. I am thinking of disabling the assignment not because I think it does not belong to references, but because there are two ways of implementing it, and implementing it either way would surprise a different group of programmers. And this would be a "run-time surprise". Instead my choice (not necessarily the best one) is to provide a "compile-time surprise". With your view of optional reference (if I got it right it is a pointer with a somewhat different syntax) your expectation of rebinding assignment comes as natural. With a different model of optional reference a non-rebinding assignment comes as more natural. I believe that optional<reference_wrapper<T>> would serve your purpose best. Or would it also introduce the lack of uniformity?