A computed key names a value, inside a type too: `readonly [evaluate]: …` uses the unique symbol `evaluate`, not the type of that name beside it (Effect's `evaluate`, `TypeId`).
A function called where it's written runs as its definition is initialized: what it uses is needed then (Effect's `Base = (() => { … Base.prototype = proto … })()`), unlike what a function body called later uses.
A namespace import has no type: in a type position its name is the file's own type of that name, or the global one, as TypeScript reads it (`Iterable<T>` beside `import * as Iterable`, `interface Scope` beside `import type * as Scope`); `Ns.Member` is still the module's. A doc example naming the namespace import leaves it as written.
A package's export used through a project module that re-exports it (`export * from "pkg"`, `export { x } from "pkg"`, `export * as ns from "pkg"`) hashes as an import of it from the package.
A type a parameter reaches by several routes is written once (shared, and still checked wherever it's used), and an object that must hold a function can't arrive as data, so it's described as that alone: Effect's schema nodes, each with a `getParser` method and reached a hundred ways, made schemas of megabytes before.
A top-level statement that only writes into one constant declared above it (filling a table, freezing it) goes with that constant: one definition, its statements run and hashed together, in a scratch file as in an import. Anything else stays refused: a statement writing into nothing (a call), into two constants, or into something not the file's; and what a function in it does later doesn't count.
Declarations that exist only in types merge with a type or class of their name into one definition, as TypeScript merges them (Effect's interfaces each have a namespace of types beside them), in a scratch file as in an import; the stored code reads back as the same definition.