Clean-room interoperability
The strongest external test of a protocol is not another BTG-controlled port. It is an unrelated engineer or organization independently reproducing the protocol semantics from public specification and sealed conformance material.
Why this is different
BTG publishes Rust, TypeScript, C#, Go, Swift and Java reproducibility baselines. Those are useful portability evidence, but because they remain BTG-controlled they are not treated as independent third-party validation.
Independent implementation path
1. Start from public material
Use the published protocol, schemas, profiles, trust material and vectors rather than BTG implementation code.
2. Own your architecture
Choose your language, libraries, internal design, test harness and repository independently.
3. Qualify behavior
Accept required valid vectors, reject required invalid vectors and publish enough evidence for another party to reproduce the run.
4. Exchange live state
Test bidirectional interoperability and recovery/portable-state behavior across independently controlled implementations.
Good languages
Rust, Go, C#, TypeScript, Java/Kotlin and Swift are especially useful because they test protocol semantics across distinct runtime and type-system assumptions. Other languages are welcome when the implementation remains independent.