+1 on the general approach of trying to find a creative solution to these sorts of issue. They do come up relatively frequently, and we don’t really have a good answer right now.
However (you saw that coming 
) this proposal sounds like it would add some non-trivial complexity to Python’s dependency resolution process (which already has an issue in that it’s not something that is documented anywhere, it’s mostly a pip internal mechanism, although we are making some inroads into breaking it out into reusable library code). And algorithmically, not all resolution algorithms can handle new dependencies being injected part way through the process - so this would limit options if we ever wanted to explore better (faster, more reliable, better error reporting) algorithms.
Also, the “ask the user” approach is problematic in non-interactive situations like CI, so we’d need to specify how the proposal would work in those situations.
And finally, this is in direct contradiction of the direction we’re trying to move in, where dependency resolution data (name, version and dependencies) is statically available from the package index, and does not require execution of package code to determine.
I’m very much in favour of exploring this idea further, but it does have some fairly substantial hurdles it will have to address if it’s going to be usable in practice.
Also, we need to remember that 99% (yes, made up number 
) of packages don’t need this sort of mechanism, so we need to take care not to end up with a solution that penalises the masses for the sake of the few.