But: The evil chosen should be the one least capable of making a mess in your project. This depends on:
* How many software clients do you have that will have to be changed when stirring things up?
* Sometimes 2 evils can be better than one: Support multiple simultaneous interfaces or versions (4th evil?) so not everyone must adapt at the same time

Shared code require a lot more forethought and careful crafting than unshared. Having good test coverage will be a good help to avoid breaking the contract accidentially, but this is no new thoughts though (at least I hope it is not)

But: The evil chosen should be the one least capable of making a mess in your project. This depends on:
* How many software clients do you have that will have to be changed when stirring things up?
* Sometimes 2 evils can be better than one: Support multiple simultaneous interfaces or versions (4th evil?) so not everyone must adapt at the same time

Shared code require a lot more forethought and careful crafting than unshared. Having good test coverage will be a good help to avoid breaking the contract accidentially, but this is no new thoughts though (at least I hope it is not)

May I add a point:
Sometimes you need a new module that starts out identical to some
other module, but actually it is totally independent of the other
module and will most likely divert more and more from it. In that case
I think you will be better off just copying the whole thing and let it
live its own life. I think.

However, I've seen many instances of code never reaching sufficient maturity before the project becomes too large to avoid a (possibly de facto) code freeze. It is important to recognize this likely failure mode and treat it serious if it occurs.

I've seen a few examples that especially domain objects end up having this fate. The open-closed principle is often not the way to go for domain entities. This means that a stable domain model soon may feel anemic.

You sketch three different approaches, that I attempt to rephrase as follows:
1. Duplicate code, so that change at one place does not affect code somewhere else, but at the cost of duplicated changes of common logic
2. Share code, to avoid duplicated changes of common logic, but at the cost of requiring change in all the clients when the logic of any of the suppliers changes
3. Do not allow changes, to avoid both of the inconveniences above, but at the cost of conserving unsatisfactory solutions

I tend to think that the solution will change over time.
* Initial code is unstable and has only a few clients. Apply approach 2.
* As code matures and stabilizes, fix its contract (precondition and postcondition). Apply rule 3 and the open/closed principle.
* A subsequent change may of may not break the contract.
1. If it does not (weaker precondtion, stronger postcondition), there is nothing to worry about – clients are not affected by the change. All tests will pass unchanged.
2. If it does, apply rule 1 and define a new function for the new contract, possibly making the old definition deprecated to leave a transision time for the clients.

Just some thoughts.