While you right that the anonymous structural opaque result types I am proposing are not general enough to address every use case on their own, they are intended as a stepping stoned to named opaque result types, as mentioned in the "future directions" section. It seems like named opaque result types are actually exactly what you're suggesting, just with a moderately different syntax from that described in the post written by Joe which I linked.
In my opinion, the syntax for named opaque result types is necessarily rather cumbersome, and the Rust ecosystem suggests that there is a large space of practical API designs where structural opaque result type are needed, but where a fully general syntax is not. I also think that implementing named opaque result types without anonymous structural opaque result types would feel like a strange hole in the language design.
Furthermore, this proposal creates a nice symmetry to generalized some syntax, another likely future direction, just as named opaque result types create a nice symmetry with generic parameter lists. You have a verbose form for when you need detailed constraints, and a friendly, terse form for the simple cases.
From a compiler implementation standpoint, the type checker work which I did to facilitate structural opaque result types will also serve to support named opaque result types.