Whether you can soundly substitute is a big sticking point, and it affects all sorts of things other than typeclasses; this was the major problem with “unboxed value classes” that was fixed so nicely by the followup opaque types proposal.
So returning to unboxed value classes would restore those problems as well, which go beyond merely whether the compiled code happens to box them.
You can do this with abstract types, too, in current Scala. It would be nice to be able to ban that, too.
That you can optionally supply =:= or <:< instances in the type companion providing unidirectional or bidirectional substitution as part of the interface is one of the great features of opaque types as currently proposed; it’s a sound way to declaratively expose part or all of the equality. (The whole substitute design space is supported, indeed.) So you can choose exactly how much of Logarithm = Double can be seen in the interface, and the language for doing so is simply defining methods.
I sure wouldn’t mind banning arbitrary type patterns and [ai]sInstanceOf calls, though.