RFC 107 - full type-directed library APIs and compile-time type tokens

[dannymeijer]

Summary

RFC 107 is a full v0.6 implementation commitment. Type tokens are narrow compiler-backed Type[T] evidence, not general runtime type objects; they enable complete type-directed APIs without string targets, helper-family duplication, or public-boundary identity drift.

Scope

• Resolve every RFC 107 decision required for Planned status, including admitted token kinds, precise generic return-mapping mechanism, type-alias provenance, and alias metadata rules.
• Implement expected-context type tokens, storage/return/collection limits, overload selection, precise type-directed return mapping, aliases, reexports, decorators, reflection boundaries, package metadata, documentation, LSP, semantic inspection, diagnostics, lowering, and backend-neutral emission.
• Prove identical callable and type behavior through same-module, import, facade, package, alias, decorator, and tolerant-tooling paths.

Boundaries

• No general first-class type objects, equality/hashing/serialization/pattern matching for tokens, arbitrary type-level computation, or new broad runtime reflection system.
• Existing explicit call-site generics and associated-type work retain their own contracts.

Delivery

• feature - RFC 107 complete Type[T] semantics and type-directed return mappings #1033 — complete Type[T] semantics and type-directed return mappings
• feature - RFC 107 public API metadata, tooling, and boundary-invariant conformance #1030 — public metadata, tooling, and boundary-invariant conformance

Done when

• RFC 107 reaches Planned status with no unresolved implementation-blocking decisions.
• Every supported type-directed API has one source-semantic and public metadata representation.
• Users can inspect selected overloads, mappings, aliases, and identities without generated backend code.