@CaseyCarter and I talked about this at the weekly maintainer meeting, and we're uncomfortable with merging this change. It injects a lot of overload complexity into STL iterators, with the potential to harm throughput and/or mess up other overload resolution scenarios. The underlying cause (at least for MSVC's STL, I dunno about libstdc++) is our undesirable "modifiable iterators inherit from const iterators" scheme, which we already know causes conformance issues and which I had already fixed in our decade-old stranded WCFB02 branch (by making our modifiable/const checked/unchecked iterators all unrelated instantiations of a single unified template per container).

Although libstdc++'s bug report came from a real program, we're unsure how common uses of expected<any, Err> will be. It's also concerning that pathological types (with forwarding references, as you presented) cause an even more difficult-to-solve problem in the library, with no Standardese clearly forbidding them.

We only have vague ideas about what we want to see happen here. Ideally vNext will happen, and we'll be able to fix our long-standing iterator wackiness and eliminate the true root cause of this problem. It would also be nice if LWG clearly said whether expected<any, Err> and/or pathological types like your any_convertible_subtractable example are required to be tolerated by STL containers.