WProto: cross-assembly subtype dispatch, currently refused with WPROTO040

[wallstop]

What

#601 asked for zero-touch subtypes and named two asks. The tag manifest shipped and answers the first: an author writes [WProtoSubtype(typeof(Base))], never picks a number, never edits the base, never reads a sibling, and add / remove / re-add preserves the wire.

The second ask is unanswered, and no tag scheme can answer it:

Let a client slap this attribute on a type in their assembly.

A subtype in a consumer's assembly deriving from a base in this package. A per-assembly generator provably cannot see it: the base's dispatch chain was emitted when the base's assembly compiled. It is refused today with WPROTO040, and #601's research recorded why the manifest deliberately does not extend to it.

Why it is a different mechanism, not a bigger manifest

A manifest cannot coordinate across repositories that never see each other. This needs a runtime registry, and its hazards are the durable-wire kind:

• Unity's registrars run unordered. A serialize that happens before every registrar has run writes under the wrong tag, or none. The registry needs freeze semantics that refuse late registration after first use.
• Two unrelated packages picking the same tag on a shared base is undetectable at build time and silently type-confusing at read time. Arbitration has to be a runtime error at registration.
• Dispatch is currently branch-only static code. A registry lookup has to stay IL2CPP-safe — no MakeGenericType — and stripping has to be told to keep formatters that nothing statically references.

Each of those failure modes is silent data corruption rather than a build error, which is why #601 refused to fold this in.

Acceptance criteria

• A consumer assembly can declare a subtype of a package base and have it round-trip, or the refusal stays and WPROTO040's message explains the permanent reason rather than implying a future.
• Registration after first use is refused loudly, not honoured.
• Two registrations claiming one tag on one base fail at registration with both type names.
• The dispatch path is IL2CPP-safe and survives managed stripping, proven on a standalone player.
• Round-trip against protobuf-net 2.4.9 and 3.2.56 is preserved in both directions, since that is the package's central promise.

Notes

WPROTO040 currently refuses this and should keep refusing it until the above holds — a build error is strictly better than a player that writes an unreadable save.

Split from #601, which shipped the same-assembly half.

[wallstop]

Decided: the refusal is permanent, in #610

Taking the second branch this issue offers, and the one PLAN.md already named the safe default. Not because the registry is hard — because every one of its failure modes is silent data corruption rather than a build error, and proving otherwise needs a standalone IL2CPP player, which is the same runner gate as #602. A build error you can see beats a player that writes an unreadable save.

What changed. WPROTO040's cross-assembly message said the base's chain "was generated when its own assembly was compiled" and left the reader to guess whether that was a limit or a gap. It now states that this is how per-assembly generation works rather than a gap waiting to be filled, and names what to write instead.

The alternative is composition, and the message says so concretely rather than by hint:

// Refused: Sub is in your assembly, Weapon is in the package's.
[WProtoContract]
[WProtoSubtype(typeof(Weapon), 100)]
public partial class PlasmaCutter : Weapon { }

// Supported: your type is its own contract and holds a Weapon.
[WProtoContract]
public partial class PlasmaCutter
{
    [WProtoMember(1)] public Weapon Base;
    [WProtoMember(2)] public float ChargeSeconds;
}

A member whose type comes from another assembly is generated normally, and Weapon still writes its own subtypes through the chain emitted with it — so a Weapon field holding a package subtype round-trips as that subtype. What you give up is being dispatched as a Weapon: a List<Weapon> cannot hold a PlasmaCutter. The docs say that plainly rather than selling the workaround as equivalent.

Two tests, because a diagnostic that names a fix has to name one that works:

• TheCrossAssemblyRefusalNamesAPermanentReasonAndAWorkingAlternative asserts the permanence clause is present and that "not yet", "for now", "until" and "in a future" are absent.
• TheAlternativeTheCrossAssemblyRefusalRecommendsGenerates compiles the composition shape against a real upstream assembly and asserts it generates clean.

Closing on merge. If the runner situation changes and you want the registry built, this issue's acceptance criteria are still the right specification for it — reopen rather than re-derive them.

[wallstop]

Correction to the closure above: the refusal is right, the framing was too strong

I closed this as permanent and worded WPROTO040 to match — "this is how per-assembly generation works rather than a gap waiting to be filled". The refusal stands and the runtime registry stays refused for exactly the reasons above. But that wording foreclosed a mechanism I had not considered, and three measurements taken afterwards show it is viable:

1. A consumer's compilation can already read the package base's [WProtoInclude] tags and every [WProtoMember] tag out of metadata. Collision detection needs no new information.
2. WProtoFormatterProvider already documents that a later registration replaces an earlier one, deliberately, so a consumer can supply a base's formatter.
3. The emitted chain is ordinary static code. Nothing requires the assembly that declared the base to be the one that emits it.

So the extending assembly could emit the base's whole dispatch chain itself — package subtypes included — and register it in place of the shipped one. No registry, no lookup, no MakeGenericType, no unordered-registrar hazard. Tag collisions become build errors, because the tags are right there in metadata.

Tracked on #612, with the one genuinely undecidable case written down: two sibling assemblies that cannot see each other both extending one base, which is arbitrated at project assembly rather than at either compilation.

WPROTO040's message and the serialization guide now state the mechanism and the working alternative, and stop predicting the future in either direction — they do not promise a release either, since the refusal is real today whatever #612 decides.

This issue stays closed: its acceptance criteria are written for the registry, and that decision has not changed.