Specification: When hashing transactions for references [1], Include a personalization field [2] which is defined by the protocol spec and is intended to change on each hardfork at the appropriate trigger height.

Example: Starting with Hardfork 0, if we use this approach we may define a global constant such as Zcash Replay Protection: HF0 <128 bits of entropy>. Later, when the "Zcash Cashy Cash" fork comes along, they would politely activate a different personalization such as Zcash Replay Protection: Zcash Cashy Cash <127 different bits of entropy>. The later forks would ensure the switch of personalization only occurs when a hardfork triggers so that their nodes can still validate pre-fork transactions.

Motivation: One nice detail about these constants is that they are not user facing so there needn't be political struggle over who gets to control a name. End-user won't ever see these and only devs and geeks need to know it exists.

Inspiration: This tweet by @SergioDemianLerner: https://twitter.com/SDLerner/status/893188548211470336?s=03

Further Analysis: I don't yet understand the implications of doing this. It is clear this will ensure nodes from different hardforks cannot validate prevout pointers or block transaction tree roots. I'm not yet comfortable with this until I understand what nodes do when they cannot validate those references. For example, if they cannot resolve a prevout they may assume it refers to a transaction not-yet-seen and therefore it will hold onto the "other fork" transaction indefinitely.

Another kind of analysis worth pursuing: what if two factions intend to cause mutually incompatible, chain-splitting, hardfork upgrades, but for unanticipated political reasons they both refuse to alter their personalization constants?

Footnotes:

[1] References include txids, such as prevout pointers, what UIs / block explorers display, etc…

[2] I use the term personalization inspired by the clean design of BLAKE2's interface. See The BLAKE2 Document, §2.8. This is a globally unique value mixed into all instances of the hash function for a given application purpose, in contrast to the term salt which often implies a unique value mixed into each instance.