Just to note, conda/conda#12245 is currently open (as a result of initial discussion on PEP 704) to add an EXTERNALLY-MANAGED file to Conda’s base environment by default, to avoid pip breaking Conda/the conda installation itself.
That’s an interesting possibility to consider, as a middle ground for non-base environments. However, I would be inclined to think that it would be sufficiently disruptive to enough existing workflows that rely on pip updating packages that were originally conda-installed for various reasons (outdated conda package, updated dependency requirements by PyPI-only package, pip install ., etc.) that it might need to be at least opt-out if not opt-in at install time. There might also be other reasons why it’s a non-starter, not sure.
There has been a lot of relevant discussion about this approach and the other mechanisms in general on the PEP 704 thread, starting roughly here. In general, the Conda folks seemed generally against this option as harming rather than helping Conda-pip interoperability, whereas the PyPA folks there believed it would help.
I’m a little unclear what you mean here by “no native package installation” here. Could you explain further? I.e. by “no native” do you mean no non-pure-Python, no pip, no conda, or something else?