I don’t think the two positions are really much different here either. @FFY00 thinks the user should be discouraged more to manually fishing out the wheel and install it elsewhere, and @pf_moore thinks the standard doesn’t need to get into such things. IMO the views aren’t even contradicting.
The way editables are implemented in both editables and setuptools use some sort of redirection logic to point an import to a path, and the only thing that can separate a working editable from a broken one is whether that redirection target exists (an existing path does not mean the redirected module will work, but that’s true for non-editable wheels as well, it’s not meaningful to get into that). PEP 657 already mandates the installer must create a
direct_url.json describing where the original project is, and the only thing left to ensuring the editable is valid from that is to check that path to the original project actually exists—if it does, the editable installation is valid as far as the installer is concerned.
So IMO whether an editable wheel is valid for installation can be determined entirely if a Python project can be found where it’s expected. If there isn’t, something is very wrong and the installer should abort. If there is, either the entire workflow is working as intended, or the user somehow fished out the editable wheel and reproduced the project it was reditecting to on another machine, which probably means they know what they’re doing and we can just let things work? We can probably add some text to advice installers to do the file path check, and that’s about enough.
 But how? The PEP says the editable wheel must look like a regular wheel, and the installer must install it like a regular wheel. Assuming the build frontend is a separate component to the installer (e.g.
pradyunsg/installer), the installer must be able to figure out on its own whether a wheel is editable to do the right thing, does it not? Should the editable wheel contain a flag somewhere to communicate this information to the installer?