A library like that would be quite useful. either to depend on or as a reference. It’d be great not to have to reinvent some of those wheels. Writing a build backend is still more work now than it should be.
For the rest: it all seems a little bit misguided. You seem to be under the impression that it’s a matter of finding some compiler, pointing it at a few source files, and producing a .so/.dll. In reality, dealing with compiled code is (at least) an order of magnitude more complex than anything that any pure Python build backend does. That’s why it can’t be just an afterthought - the details actually matter.
I’m fairly sure it’s not. It may be a reasonable way of addressing the use case of “user uses my pure Python backend already, and now wants to add a single Cython file - how do I help them out?”. But that’s about it. You have pretty much misunderstood PEP 517’s intent (no one had anything like this in mind - the point is to have multiple build backends), and as @dholth pointed out, many tools won’t work like that (out of the ones you listed, probably only Cython does). I suspect you’ll find out as soon as you try to implement a plugin like that on a non-trivial project. There’s many more issues, from UX ones (which of hatchling and the plugged-in build system uses which --config-settings?) to more fundamental ones like passing source files being wrong in general (tools need their own config files, where sources are listed) and editable installs for an out-of-tree build tool needing unified Python/native-code support. And then we haven’t even started on non-PyPI dependencies, code generation, cross-compilation, etc.
If you want Hatch to be general then it should work with multiple build backends. For this discussion, that’s probably the key thing. Making build backends easier to write by providing a library is great too.