Mainnet compatibility of Plutus releases is not discoverable

[Unisay]

Problem

Raised by @colll78.

Right now, if a developer wants to know "does the code I compile with this Plutus release actually work on mainnet?" there's no good answer in the repo.

Which Plutus version is on mainnet? You have to find the latest production cardano-node release, trace its dependency chain to the Plutus version it pulled in, then check out that version to see what it supports.

Which features are mainnet-safe? The Plutus Tx plugin has flags that affect compatibility (target-version, datatypes encoding style), but nothing in the repo says whether the current defaults produce mainnet-compatible code, which features (e.g. builtin-casing) need a protocol version that isn't live yet, or what flags to set.

Most Cardano smart contract developers aren't Haskell developers. The compatibility info is buried in Haskell types and protocol version guards. @colll78 regularly gets asked by devs what's supported on mainnet and has to explain protVersion, walk through where it's defined for each builtin, etc.

This also gets worse over time. Right after a hard fork, the latest Plutus release matches mainnet. Then we add features (like casing on builtins) and the default compilation output drifts ahead of what's deployed, with no signal in the repo when that happens.

Where things stand

• target-version controls the target Plutus Core version (defaults to 1.1.0)
• datatypes controls encoding style (scott-encoding, sums-of-products, builtin-casing)
• Cost model variants are named A/B/C. On chain, C is used for PlutusV3 scripts and B for PlutusV1/V2 (A was pre-Chang). But the checked-in models don't necessarily match what's on chain at any given moment -- new builtins get added before their cost model parameters are deployed, and the timing of parameter updates relative to hard forks adds further complexity. None of this is obvious from the naming or the code.
• Nothing in the repo marks the last mainnet-compatible state