So I took a look at flit. It has two kinds of editable installs. One uses symlinks to link the install into site-packages. The other adds a .pth entry, more like how setuptools does it and more compatible with Windows.
I don’t think it would be practical to do the symlink option with enscons. It’s more like a set of tools to make it easy to build wheels than a fixed system. The files that wind up inside the wheel could come from all over, or be generated directly into the wheel and come from nowhere at all. It does have the concept of src_root, where you put your code, usually “.” or “src”.
For enscons a decent installer-driven develop() would be required to emit a dist-info directory in src_root, and it would return src_root as an absolute path, or as a relative path from pyproject.toml. The installer would maintain the .pth file or whatever mechanism it used to add us to PYTHONPATH.
A develop() hook could return different keys in a dict depending on what kind of editable install the back end was able to support.