OK I got convinced in 1 thing: If, we had built wheels, and handle conflicts with dependencies at the stage where python.withPackages environments are created, and not at the build stage of packages, all of my suffering would have been spared - because choosing to use numpy_2 instead of numpy_1 would not require rebuilding heavy packages like Scipy which don’t depend directly on Numpy’s shared objects etc… That’s still very far in the future, and so I guess it is not that bad in that outlook to keep propagating a single numpy version, although both are supported, and although the propagated version is outdated.
Now I understand that all of the topics I raised above really sum up together to the correct policies the Python maintainers try to enforce. But still though, these could be communicated a bit better, and that can be handled in better documentation, which hopefully the Python maintainers will agree to improve.
I think the python.section.md file should explain the goals of long and on-going processes such as this, even if they are not complete, and explain the drawbacks of alternative workarounds to issues such as discussed here. This kind of documentation is not common in our ecosystem, and it is unfortunate IMO, but that’s a topic for a different thread.