@@ -47,14 +47,14 @@ To contribute to any of these repositories, see the Community Group's
 [Design Choices]: design/high-level/Choices.md
 [FAQ]: design/high-level/FAQ.md
 [WIT]: design/mvp/WIT.md
-[Text Format]: design/mvp/Explainer.md
+[Text Format]: design/mvp/Text.md
 [Binary Format]: design/mvp/Binary.md
 [Linking]: design/mvp/Linking.md
 [Concurrency]: design/mvp/Concurrency.md
 [ABI]: design/mvp/CanonicalABI.md
 [WAST test suite]: test/
 [formal spec]: spec/
-[Gated Features]: design/mvp/Explainer.md#gated-features
+[Gated Features]: design/mvp/Text.md#gated-features
 [W3C WebAssembly Community Group]: https://www.w3.org/community/webassembly/
 [Contributing Guidelines]: https://webassembly.org/community/contributing/
 [WASI]: https://github.com/WebAssembly/WASI
@@ -1,7 +1,7 @@
 # Component Model Binary Format Explainer
 
 This document defines the binary format for the AST defined in the
-[explainer](Explainer.md). The top-level production is `component` and the
+[explainer](Text.md). The top-level production is `component` and the
 convention is that a file suffixed in `.wasm` may contain either a
 [`core:module`] *or* a `component`, using the `layer` field to discriminate
 between the two in the first 8 bytes (see [below](#component-definitions) for
@@ -12,13 +12,13 @@ rules, but rather merge the minimal need-to-know elements of both, with just
 enough detail to create a prototype. A complete definition of the binary format
 and validation will be present in the [formal specification](../../spec/).
 
-See [Gated Features](Explainer.md#gated-features) for an explanation of emoji
+See [Gated Features](Text.md#gated-features) for an explanation of emoji
 annotations like 🪙 and 🔧.
 
 
 ## Component Definitions
 
-(See [Component Definitions](Explainer.md#component-definitions) in the explainer.)
+(See [Component Definitions](Text.md#component-definitions) in the explainer.)
 ```ebnf
 component ::= <preamble> s*:<section>*            => (component flatten(s*))
 preamble  ::= <magic> <version> <layer>
@@ -58,7 +58,7 @@ Notes:
 
 ## Instance Definitions
 
-(See [Instance Definitions](Explainer.md#instance-definitions) in the explainer.)
+(See [Instance Definitions](Text.md#instance-definitions) in the explainer.)
 ```ebnf
 core:instance       ::= ie:<core:instanceexpr>                             => (instance ie)
 core:instanceexpr   ::= 0x00 m:<moduleidx> arg*:vec(<core:instantiatearg>) => (instantiate m arg*)
@@ -114,7 +114,7 @@ Notes:
 
 ## Alias Definitions
 
-(See [Alias Definitions](Explainer.md#alias-definitions) in the explainer.)
+(See [Alias Definitions](Text.md#alias-definitions) in the explainer.)
 ```ebnf
 alias ::= s:<sort> 0x00 i:<instanceidx> n:<name>           => (alias export i n (s))
         | s:<sort> 0x01 i:<core:instanceidx> n:<core:name> => (alias core export i n (s))
@@ -137,7 +137,7 @@ Notes:
 
 ## Type Definitions
 
-(See [Type Definitions](Explainer.md#type-definitions) in the explainer.)
+(See [Type Definitions](Text.md#type-definitions) in the explainer.)
 ```ebnf
 core:type        ::= dt:<core:deftype>                                    => (type dt)
 core:deftype     ::= rt:<core:rectype>                                    => rt               (WebAssembly 3.0)
@@ -276,7 +276,7 @@ Notes:
   `instancetype`. Thus, handle types inside a `componenttype` can only refer
   to resource types that are imported or exported.
 * `<label>` is defined as part of the
-   [text format](Explainer.md#import-and-export-definitions).
+   [text format](Text.md#import-and-export-definitions).
 * All parameter labels, result labels, record field labels, variant case
   labels, flag labels, enum case labels, component import names, component
   export names, instance import names and instance export names must be
@@ -294,7 +294,7 @@ Notes:
 
 ## Canonical Definitions
 
-(See [Canonical Definitions](Explainer.md#canonical-definitions) in the explainer.)
+(See [Canonical Definitions](Text.md#canonical-definitions) in the explainer.)
 ```ebnf
 canon    ::= 0x00 0x00 f:<core:funcidx> opts:<opts> ft:<typeidx> => (canon lift f opts type-index-space[ft])
            | 0x01 0x00 f:<funcidx> opts:<opts>                   => (canon lower f opts (core func))
@@ -371,7 +371,7 @@ Notes:
 
 ## 🪙 Start Definitions
 
-(See [Start Definitions](Explainer.md#start-definitions) in the explainer.)
+(See [Start Definitions](Text.md#start-definitions) in the explainer.)
 ```ebnf
 start ::= f:<funcidx> arg*:vec(<valueidx>) r:<u32> => (start f (value arg)* (result (value))ʳ)
 ```
@@ -393,7 +393,7 @@ flags are set.
 
 ## Import and Export Definitions
 
-(See [Import and Export Definitions](Explainer.md#import-and-export-definitions)
+(See [Import and Export Definitions](Text.md#import-and-export-definitions)
 in the explainer.)
 ```ebnf
 import         ::= na:<nameattributes> et:<externtype>                  => (import na et)
@@ -416,7 +416,7 @@ Notes:
   `externtype` immediate is present, validation requires it to be a supertype
   of the inferred `externtype` of the `sortidx`.
 * `<externname>`, `<interfacename>` and `<semversuffix>` are defined as part of
-  the [text format](Explainer.md#import-and-export-definitions).
+  the [text format](Text.md#import-and-export-definitions).
 * The redundant `0x00`/`0x01` cases of `nameattributes` will
   [be cleaned up for a 1.0 release](#binary-format-warts-to-fix-in-a-10-release).
 * The `externname`s of all imports in a given component or component-type must
@@ -472,7 +472,7 @@ Notes:
 
 ## 🪙 Value Definitions
 
-(See [Value Definitions](Explainer.md#value-definitions) in the explainer.)
+(See [Value Definitions](Text.md#value-definitions) in the explainer.)
 
 ```ebnf
 value                      ::= t:<valtype> len:<core:u32> v:<val(t)>   => (value t v) (where len = ||v||)
@@ -594,7 +594,7 @@ named once.
 [`core:functype`]: https://webassembly.github.io/spec/core/binary/types.html#binary-functype
 [`core:rectype]: https://webassembly.github.io/gc/core/binary/types.html#recursive-types
 
-[Strongly-unique]: Explainer.md#name-uniqueness
+[Strongly-unique]: Text.md#name-uniqueness
 
 [type-imports]: https://github.com/WebAssembly/proposal-type-imports/blob/master/proposals/type-imports/Overview.md
 [module-linking]: https://github.com/WebAssembly/module-linking/blob/main/proposals/module-linking/Explainer.md
 
@@ -2,7 +2,7 @@
 
 This document defines the Canonical ABI used to convert between the values and
 functions of components in the Component Model and the values and functions
-of modules in Core WebAssembly. See the [AST explainer](Explainer.md) for a
+of modules in Core WebAssembly. See the [AST explainer](Text.md) for a
 walkthrough of the static structure of a component and the [concurrency
 explainer] for a high-level description of the concurrency concepts being
 specified here.
@@ -4817,7 +4817,7 @@ def canon_error_context_new(opts, ptr, tagged_code_units):
   return [i]
 ```
 Supporting the requirement (introduced in the
-[explainer](Explainer.md#error-context-type)) that wasm code does not depend on
+[explainer](Text.md#error-context-type)) that wasm code does not depend on
 the contents of `error-context` values for behavioral correctness, the debug
 message is completely discarded nondeterministically or, in the deterministic
 profile, always. Importantly (for performance), when the debug message is
@@ -4984,13 +4984,13 @@ def canon_thread_available_parallelism():
 
 
 [Virtualization Goals]: Goals.md
-[Canonical Definitions]: Explainer.md#canonical-definitions
-[`canonopt`]: Explainer.md#canonical-definitions
-[`canon`]: Explainer.md#canonical-definitions
-[Type Definitions]: Explainer.md#type-definitions
-[Component Invariant]: Explainer.md#component-invariants
-[JavaScript Embedding]: Explainer.md#JavaScript-embedding
-[ESM-integration]: Explainer.md#esm-integration
+[Canonical Definitions]: Text.md#canonical-definitions
+[`canonopt`]: Text.md#canonical-definitions
+[`canon`]: Text.md#canonical-definitions
+[Type Definitions]: Text.md#type-definitions
+[Component Invariant]: Text.md#component-invariants
+[JavaScript Embedding]: Text.md#JavaScript-embedding
+[ESM-integration]: Text.md#esm-integration
 [Adapter Functions]: FutureFeatures.md#custom-abis-via-adapter-functions
 [Shared-Everything Dynamic Linking]: examples/SharedEverythingDynamicLinking.md
 [Concurrency Explainer]: Concurrency.md
 
@@ -1541,32 +1541,32 @@ the concurrency story:
 [`waitUntil`]: https://developer.mozilla.org/en-US/docs/Web/API/ExtendableEvent/waitUntil
 [`setInterval`]: https://developer.mozilla.org/en-US/docs/Web/API/Window/setInterval
 
-[AST Explainer]: Explainer.md
-[Canonical Built-in]: Explainer.md#canonical-built-ins
-[Component Invariant]: Explainer.md#component-invariants
-[`context.get`]: Explainer.md#-contextget
-[`context.set`]: Explainer.md#-contextset
-[`backpressure.inc`]: Explainer.md#-backpressureinc-and-backpressuredec
-[`backpressure.dec`]: Explainer.md#-backpressureinc-and-backpressuredec
-[`task.return`]: Explainer.md#-taskreturn
-[`task.cancel`]: Explainer.md#-taskcancel
-[`subtask.cancel`]: Explainer.md#-subtaskcancel
-[`waitable-set.new`]: Explainer.md#-waitable-setnew
-[`waitable-set.wait`]: Explainer.md#-waitable-setwait
-[`waitable-set.poll`]: Explainer.md#-waitable-setpoll
-[`waitable.join`]: Explainer.md#-waitablejoin
-[`thread.index`]: Explainer.md#-threadindex
-[`thread.new-indirect`]: Explainer.md#-threadnew-indirect
-[`thread.resume-later`]: Explainer.md#-threadresume-later
-[`thread.suspend`]: Explainer.md#-threadsuspend
-[`thread.yield`]: Explainer.md#-threadyield
-[`thread.suspend-then-resume`]: Explainer.md#-threadsuspend-then-resume
-[`thread.yield-then-resume`]: Explainer.md#-threadyield-then-resume
-[`thread.suspend-then-promote`]: Explainer.md#-threadsuspend-then-promote
-[`thread.yield-then-promote`]: Explainer.md#-threadyield-then-promote
-[`{stream,future}.new`]: Explainer.md#-streamnew-and-futurenew
-[`{stream,future}.{read,write}`]: Explainer.md#-streamread-and-streamwrite
-[`stream.cancel-write`]: Explainer.md#-streamcancel-read-streamcancel-write-futurecancel-read-and-futurecancel-write
+[AST Explainer]: Text.md
+[Canonical Built-in]: Text.md#canonical-built-ins
+[Component Invariant]: Text.md#component-invariants
+[`context.get`]: Text.md#-contextget
+[`context.set`]: Text.md#-contextset
+[`backpressure.inc`]: Text.md#-backpressureinc-and-backpressuredec
+[`backpressure.dec`]: Text.md#-backpressureinc-and-backpressuredec
+[`task.return`]: Text.md#-taskreturn
+[`task.cancel`]: Text.md#-taskcancel
+[`subtask.cancel`]: Text.md#-subtaskcancel
+[`waitable-set.new`]: Text.md#-waitable-setnew
+[`waitable-set.wait`]: Text.md#-waitable-setwait
+[`waitable-set.poll`]: Text.md#-waitable-setpoll
+[`waitable.join`]: Text.md#-waitablejoin
+[`thread.index`]: Text.md#-threadindex
+[`thread.new-indirect`]: Text.md#-threadnew-indirect
+[`thread.resume-later`]: Text.md#-threadresume-later
+[`thread.suspend`]: Text.md#-threadsuspend
+[`thread.yield`]: Text.md#-threadyield
+[`thread.suspend-then-resume`]: Text.md#-threadsuspend-then-resume
+[`thread.yield-then-resume`]: Text.md#-threadyield-then-resume
+[`thread.suspend-then-promote`]: Text.md#-threadsuspend-then-promote
+[`thread.yield-then-promote`]: Text.md#-threadyield-then-promote
+[`{stream,future}.new`]: Text.md#-streamnew-and-futurenew
+[`{stream,future}.{read,write}`]: Text.md#-streamread-and-streamwrite
+[`stream.cancel-write`]: Text.md#-streamcancel-read-streamcancel-write-futurecancel-read-and-futurecancel-write
 [Donut Wrapping]: Linking.md#higher-order-shared-nothing-linking-aka-donut-wrapping
 
 [Canonical ABI Explainer]: CanonicalABI.md
@@ -1583,8 +1583,8 @@ the concurrency story:
 [Binary Format]: Binary.md
 [WIT]: WIT.md
 [Blast Zone]: FutureFeatures.md#blast-zones
-[`start`]: Explainer.md#start-definitions
-[JS API]: Explainer.md#JS-API
+[`start`]: Text.md#start-definitions
+[JS API]: Text.md#JS-API
 
 [Store]: https://webassembly.github.io/spec/core/exec/runtime.html#syntax-store
 [Deterministic Profile]: https://webassembly.github.io/spec/versions/core/WebAssembly-3.0-draft.pdf#subsubsection*.798
 
@@ -69,6 +69,6 @@ as originally proposed.
 [Adapter Functions]: https://github.com/WebAssembly/interface-types/blob/main/proposals/interface-types/Explainer.md#adapter-functions
 [Scoping and Layering Proposal]: https://docs.google.com/presentation/d/1PSC3Q5oFsJEaYyV5lNJvVgh-SNxhySWUqZ6puyojMi8
 [`list.lift_canon` and `list.lower_canon`]: https://github.com/WebAssembly/interface-types/blob/main/proposals/interface-types/Explainer.md#optimization-canonical-representation
-[Component Invariants]: Explainer.md#component-invariants
+[Component Invariants]: Text.md#component-invariants
 [GC-free Runtime Instantiation]: https://docs.google.com/presentation/d/1PSC3Q5oFsJEaYyV5lNJvVgh-SNxhySWUqZ6puyojMi8/edit#slide=id.gd06989d984_1_274
 [Core Module Linking]: https://github.com/WebAssembly/module-linking/blob/63cd6c0e3ac5c0cdb798a985790f51ccdd77af00/proposals/module-linking/Explainer.md
@@ -321,8 +321,8 @@ future features of WIT and the Component Model.)
 [Canonical ABI]: CanonicalABI.md
 [Binary Format]: Binary.md
 [WIT]: WIT.md
-[`external-id`]: Explainer.md#import-and-export-definitions
-[ESM-integration]: Explainer.md#esm-integration
+[`external-id`]: Text.md#import-and-export-definitions
+[ESM-integration]: Text.md#esm-integration
 
 [WebAssembly/tool-conventions]: https://github.com/WebAssembly/tool-conventions
 [WebAssembly Object File]: https://github.com/WebAssembly/tool-conventions/blob/main/Linking.md
 
@@ -29,7 +29,7 @@ See [Gated Features] for an explanation of emoji like 🔧 and 🏷️.
 
 [IDL]: https://en.wikipedia.org/wiki/Interface_description_language
 [components]: https://github.com/webassembly/component-model
-[Gated Features]: Explainer.md#gated-features
+[Gated Features]: Text.md#gated-features
 
 ## Package Names
 
@@ -86,7 +86,7 @@ Package names are used to generate the [names of imports and exports]
 in the Component Model's representation of [`interface`s][interfaces] and
 [`world`s][worlds] as described [below](#package-format).
 
-[names of imports and exports]: Explainer.md#import-and-export-definitions
+[names of imports and exports]: Text.md#import-and-export-definitions
 
 ## WIT Interfaces
 [interfaces]: #wit-interfaces
@@ -262,7 +262,7 @@ declared. In the case of worlds, all imported names are in the same scope,
 but separate from all the export names, and thus the same name can *not* be
 imported twice, but *can* be both imported and exported.
 
-[Plain Name]: Explainer.md#import-and-export-definitions
+[Plain Name]: Text.md#import-and-export-definitions
 
 ### Union of Worlds with `include`
 
@@ -824,7 +824,7 @@ defined within each language as well.
 [identifiers]: #wit-identifiers
 
 Identifiers in WIT can be defined with two different forms. The first is the
-[kebab-case] [`label`](Explainer.md#import-and-export-names) production in the
+[kebab-case] [`label`](Text.md#import-and-export-names) production in the
 Component Model text format.
 
 ```wit
@@ -1421,7 +1421,7 @@ As a future extension, WIT, components and component registries may allow
 nesting both namespaces and packages, which would then generalize the syntax of
 `use-path` as suggested by the 🪺 suffixed rule.
 
-[Interface Name]: Explainer.md#import-and-export-definitions
+[Interface Name]: Text.md#import-and-export-definitions
 
 ## Item: `world`
 
@@ -1508,7 +1508,7 @@ world my-world {
 }
 ```
 
-[`componenttype`]: Explainer.md#type-definitions
+[`componenttype`]: Text.md#type-definitions
 
 ## Item: `include`
 
@@ -1582,7 +1582,7 @@ replacing the `func` keyword with `get` or `set`. Such functions cannot be
 async and have additional restrictions on their parameters and results as
 defined in [Binary.md](Binary.md#import-and-export-definitions). Each setter
 must have a corresponding getter with the same name (not just equal under
-[strong uniqueness](Explainer.md#name-uniqueness)), though in WIT the getter
+[strong uniqueness](Text.md#name-uniqueness)), though in WIT the getter
 and setter may appear in any order. For example, the following definitions:
 
 ```wit
@@ -1801,7 +1801,7 @@ written return type and are given the implicit return type `r`.
 📡 A resource statement can also contain any number of *getters* and
 *setters*, which may or may not be static. Every setter must have a
 corresponding getter with the same name (not just equal under [strong
-uniqueness](Explainer.md#name-uniqueness)) and same static-ness, though the two
+uniqueness](Text.md#name-uniqueness)) and same static-ness, though the two
 may appear in any order. The parameter and return types of getters and setters
 have extra restrictions defined in [Binary.md](Binary.md#import-and-export-definitions).
 
@@ -2052,7 +2052,7 @@ record bar2 {
 [package-format]: #package-format
 
 Each top-level WIT definition can be compiled into a single canonical
-Component Model [type definition](Explainer.md#type-definitions) that
+Component Model [type definition](Text.md#type-definitions) that
 captures the result of performing the type resolution described above. These
 Component Model types can then be exported by a component along with other
 sorts of exports, allowing a single component to package both runtime
@@ -2069,7 +2069,7 @@ Using component binaries to package WIT in this manner has several advantages:
   downstream tooling, similar to what has happened with the Core WebAssembly
   WAT text format over time.
 * When components are published in registries and assigned names (see the
-  discussion of naming in [Import and Export Definitions](Explainer.md#import-and-export-definitions)),
+  discussion of naming in [Import and Export Definitions](Text.md#import-and-export-definitions)),
   WIT interfaces and worlds can be published with the same tooling and named
   using the same `namespace:package/export` naming scheme.
 * A single package can both contain an implementation and a collection of
@@ -2251,7 +2251,7 @@ able to be used to compile a component without additional type information.
 
 🏷️ When a world imports or exports a named interface with a custom plain name
 (using the `id: use-path` syntax), the encoding uses the `(implements "I")`
-annotation defined in [Explainer.md](Explainer.md#import-and-export-definitions) to indicate which
+annotation defined in [Text.md](Text.md#import-and-export-definitions) to indicate which
 interface the instance implements. Note though that each copy implements a
 unique version of the interface in question. For example, the following WIT:
 
@@ -2306,7 +2306,7 @@ The `(implements "local:demo/store")` prefix tells bindings generators and
 toolchains which interface each plain-named instance import implements, while
 the labels `one` and `two` provide distinct plain names. This is a case of
 the general `(implements ..)` pattern described in
-[Explainer.md](Explainer.md#import-and-export-definitions). Also note here that
+[Text.md](Text.md#import-and-export-definitions). Also note here that
 two copies of the `"bucket"` resource are imported for the `local:demo/w` world.
 This is because the interfaces `one` and `two` duplicate the `store` interface.
 Note that this can import just a single `bucket` resource by extracting out the
 
@@ -13,7 +13,7 @@ should be able to leverage off existing support for native dynamic linking (of
 
 Shared-everything dynamic linking should be *complementary* to the
 shared-nothing dynamic linking of components described in the
-[explainer](../Explainer.md). In particular, dynamically-linked modules must not
+[explainer](../Text.md). In particular, dynamically-linked modules must not
 share linear memory across component instance boundaries. For example, we want
 the static dependency graph on the left to produce the runtime instance graph
 on the right:
 
@@ -1,5 +1,5 @@
 ;; Tests for `[constructor]`/`[method]`/`[static]` annotated plainnames
-;; (Explainer.md#import-and-export-definitions and the import/export
+;; (Text.md#import-and-export-definitions and the import/export
 ;; validation rules of Binary.md).
 
 ;; `[constructor]a` requires a single `(own $a)` or `(result (own $a) (error E)?)`