I considered the problem again and have some second thoughts. Since pip install -e is only possible with setuptools, build-system.requires being ignored is probably not that critical; situations this makes a tangible difference is likely rare. While it would still be terrible for those affected, I don’t peronsally think tit outweights pushing the revert as soon as possible.
So now I am +1 to releasing as-is. Sorry for the disturbance.
The thing is --no-use-pep517 didn’t unbreak things for me. That was a test I tried and left before I just reverted to a version of pip where that flag didn’t matter. It just ceased being relevant when I found an easier fix for my situation, i.e., pip install -U 'pip<19.0'.
If anything, this reveals that a weirdly-named, transient config option like --no-use-pep517 is only going to cause more problems. Let those of us who combine both PEP 517 and -e in our workflows deal with the fallout once those things settle down re: editable installs.
Using pip@master now with pip install -e . uses PEP 518 isolation, but not PEP 517 backend hooks. And this is critical for those of use who need setuptools + other things (such as cython) to build. Fortunately this only seems to apply to using the --no-use-pep517 flag, which we can now drop.
The thing is
--no-use-pep517didn’t unbreak things for me.
Concur, it didn’t work for me, either. pip 19.1 refused to allow disable of PEP517 with build-backend specified in my pyproject.toml. So, I would hazard a guess that most workarounds in the wild are not even using --no-use-pep517.
I would further guess that the most common workaround is simply pinning pip to an earlier version. I appreciate the effort that goes into trying to avoid bigger breaking changes, but I think in most cases, any breaks to the editable install that are introduced later should be addressed then, rather than by relying on a weird transition flag (with now confusingly different behavior between the few versions it exists in).
Does travis not give control of pip versions very well? I’m working with dockerized CI mostly, so I can pin pip back easily but I don’t know if this is the use case for a lot of people?
I suspect there are multiple approaches, but I found pinning pip in Travis to be as easy as adding something like - pip install -U --force-reinstall pip==19.0.3 to my install step.
pip 19.1.1 is now out, thanks for everyone who made this possible 
Editable install works cleanly for my CI on pip 19.1.1.
The current version of pip will invoke enscons’ emulated setup.py develop command, as long as the .egg-info has already been built.