This is how i see it. We all first learned how a = raw pointer works, and we keep in mind all its semantics. Then, we get shar= ed_ptr, and it is different than a raw pointer, but it is still significant= ly similar, that we can still call it a pointer. Then, we have unique_ptr, = which is even more different. For instance, your example:

&nbs= p; auto x =3D y;
*x =3D 2;

fails to compile if y is a unique_ptr. But it can still be thought = of as a pointer, because parts of the reasoning for raw pointers still appl= ies to unique_ptr. Now, optional is even less similar to a pointer, but it = still has some similarities. And there is enough similarities to have some = algorithms work both on pointers and optional. During these discussions I w= as already able to identify at least four algorithms:

// Not entirely C++ syntax=
, but you get the idea

auto less_pointees(N=
ullableProxy const&=
 x, NullableProxy const& y)<=
br>{
  return (!y) ? false<=
/span> :(!x) ? true: *x < *y;}<=
span style=3D"color: #000;" class=3D"styled-by-prettify">

auto equal_pointees(NullableProxy const& x, NullableProxy =
const&=
 y<=
span style=3D"color: #660;" class=3D"styled-by-prettify">)
{
  return bool(x) !=3D bool(y) ? false : bool(x=
) <=
span style=3D"color: #660;" class=3D"styled-by-prettify">=3D=3D false ? true : *x =3D=3D *y;<=
br>}

<=
span style=3D"color: #008;" class=3D"styled-by-prettify">auto get_value_or(NullableProxy && np, U && val)
{
  <=
/span>return bool(np) ? *np : val; // + forward/move
}


auto to_pointer(=
NullableProxy &&=
amp; np)
{
  return bool(np) ? addressof(*np) : n=
ullptr;
}


auto less_value(NullableProxy const& x, U &=
& y)
{
  return (!x)=
 ?<=
span style=3D"color: #000;" class=3D"styled-by-prettify"> true : *x &l=
t; y;
}

Thus, = because Identifying the common parts is useful, it is beneficial to identif= y what aspects of pointers are relevant for "abstracting" type requirements= NullableProxy, and which aren't. And conversely, there are some aspects of= pointer semantics that are irrelevant (and can be dropped) when abstractin= g the concept. We need operator* to express algorithms common to NullablePr= ioxy concepts, but we are only interested in one aspect of it: giving us th= e reference to the hidden value (regardless of where it is located and how = it is copied -- NullableProxies do not have to be copyable or moveable). Th= e other parts of the semantics of pointers are dropped when abstracting.
operator* offers a couple of things. I do not think there is anything= that requires of us are using all of its semantics.

Typically you = would expect of operator* (for multiplication) to be commutative. Do you co= nsider providing operator* for matrix multiplication a design error then?