Hi all (and @dan-zheng and @rxwei) specifically:
The core team met to discuss what to do in this situation. Most importantly, it was observed that there is a misunderstanding of the proposal, and it should be completely unnecessary to use disjunction constraints in the type checker.
The proposal is explicit that ambiguity in the two cases is resolved based on the syntax of a given call site - whether keyword arguments are present or not. Return type overloading is not intended to be supported by the proposal, and supporting that would be an extension beyond what was accepted. No one is aware of motivation for making that extension.
I'm not sure if this observation is enough to unblock the implementation work (I suspect it might be), but if not, there core team also agreed that it is perfectly reasonable to incrementally land partial progress towards the entire proposal (this has occurred many times in the past), so long as the incremental progress doesn't accept invalid code and any limitations are clearly described in error messages.
Specifically in this case, it would be fine to land a patch that:
- Faithfully implements support for types that implement one or the other of the methods, but not both.
- Diagnose with a "not supported yet" error message if someone defines a type that defines both.
There was no desire or interest in having a formal review cycle to change the proposal. Thank you so much for driving this forward, I really appreciate it!
-Chris