For the record, although I’m not interested in the proposal itself, I think we benefit from learning about the use cases which motivate it.
Does this strategy work for you today? I wouldn’t expect it to handle a second package.
If you have pkgA and pkgB as dependencies, and want to “import their locks/constraints”, they will quite likely conflict.
I think that there is another layer to unpack here in terms of your requirements. You say you want to get the same environment as what the library maintainers tested, but that’s impossible to guarantee. You could have a different Python version – even a different point release – or be running on a different OS, etc etc. If your tests pass, and your application has its own lockfile, ideally that would be good enough.
I get that you want to be assured – to the best of our ability with existing tools – that you get a working environment. But something is not lining up here for me in understanding what the “ingredients” are for the environment you’re building. Is there only one dependency?