Split out of #2162 and deliberately NOT counted in its statistics. #2162 is about the DECLARATION `pub const Name(T) = struct { ... }`, fixed in branch `w699-generic-const-decl` (ADR-008). This issue is about the APPLICATION of such a type: using `Name(T)` in a type position. ## Measured Baseline binary `/tmp/t27c.m2162base` vs candidate `/tmp/t27c.m2162fix`, library corpus (634 specs, `specs` minus `specs/scratch`), 12 s threshold: - 27 files had their first parse error move LATER after the declaration fix. The new first error is the application form. - Of the 27 files in the error signature `Expected LBrace, got LParen/RParen`, the failing line contains a generic type application in **18**; a newtype form `struct Name(str);` in **5** (`account/repo.t27`, `account/schema.t27`, `auth/config.t27`, `file/watcher.t27`, `shell/process.t27` -- possibly a separate question); and something else in 2 (`math/pellis_precision_verify.t27` line 88 `for i in 0..len(s) {`, `runtime/execute.t27` line 238, a function-type parameter `resolve_fn: fn(TaskResult) void`). - Independent count over the corpus: 8 files use return-position application with letter parameters, 30 use parameter-position, union of declaration and application = 34 files. Representative failing lines: ``` specs/tri/collections/list.t27:24 fn empty() -> List(void) { specs/tri/collections/map.t27:23 fn empty() -> Map(K, V) { specs/tri/collections/either.t27:34 fn is_left(either: Either(L, R)) -> void { specs/tri/collections/maybe.t27:28 fn bind(maybe: Maybe(T)) -> void { specs/tri/collections/set.t27:27 fn add(set: *HashSet(T)) -> void { specs/tri/graph/graph.t27:33 fn add_node(graph: *Graph(T)) -> void { ``` Note that `-> P(2)`, `-> Z(1)` and `-> N(0)` parse fine today. Those are a different construct (numeric argument), so the parser is not uniformly rejecting `Ident(...)` in return position. ## What this issue is NOT It is not a claim that the parser is wrong. Consistent use across 20 files is evidence of intent, not a specification. Accepting the application form is a language decision, exactly as the declaration form was, and it needs the same treatment: an ADR fixing the AST contract BEFORE any parser edit -- including how `Name(T)` in a type position is distinguished from a call expression, and whether `*Name(T)` binds as pointer-to-application. Until that decision exists, these 20 files stay classified `unrelated-parse-failure` and are not attributed to #2162. Refs #2162