Currently rattler-build supports building conda packages that will have the host prefix replaced in built binaries at install time by conda using similar logic to conda-build as of #598. However, there are flaws with this approach. As discussed extensively in rapidsai/cudf#18251 (comment) and rapidsai/cudf#18251 (comment) (those two comments give a complete picture of exactly how this failed), a sufficiently smart compiler can always produce a binary for which binary prefix replacement is unsafe, regardless of suitable null character padding or other safety checks. In conda/conda-build#1674 (comment), I proposed that conda-build offer a new option to error on package build if such a prefix is detected, since in practice the best solution to these kinds of problems is to fix the package source or build process to avoid embedding the host prefix in the first place. With rattler-build, as a newer packaging tool we have more flexibility and I would suggest that we go further.

I think the default behavior of rattler-build should be to error if the prefix is in the binary. This can be implemented fairly trivially using an extra flag in the config and by checking the value of contains_prefix_binary here. My reasoning for this is that it is easy enough for a project to opt in to prefix patching if there is absolutely no way they can avoid the need, but at least if it is opt in they must know what they are choosing and accept the potential pitfalls and maybe know where to look if something goes wrong. Conversely, if patching is automatic the error modes are potentially arbitrarily bad (silent failures, data corruption, program crashes) and extremely difficult to debug. Realistically most developers would struggle to fully debug a problem like rapidsai/cudf#18251 and trace it back to conda's binary prefix replacement as the source. If at all possible, we should encourage packages to fix their source code and build process to avoid needing binary prefix patching rather than having them implicitly rely on this behavior without realizing it.

Text prefix patching
As an aside, I also have a weak preference for the same behavior in text prefix patching, but in that case I think the problems are far less difficult to debug and also the process is far less likely to go wrong in unpredictable ways, so I am less concerned with the behavior there.