Future: additive `concurrent-tests` interface (concurrent runs + streaming enumeration)

[lann]

A suite-side additive interface declaring tolerance for overlapping tasks, sketched:

/// Exported in addition to `tests` by suites that tolerate overlapping
/// tasks: concurrent `run` calls, and execution overlapping enumeration.
interface concurrent-tests {
    use tests.{test-case};
    all: func() -> stream<test-case>;
}

Rationale

• Concurrent runs and streaming enumeration are the same claim. Streaming all only pays off if the runner executes cases while the all() task is still live in the suite instance — which is already overlapping-tasks-in-one-instance. One interface names one capability.
• The declaration is structural: interface presence is in the component type — type-checked, visible to composition tooling, no lockfile-sidecar drift.
• Population alignment: a returned stream that the callee feeds requires an async lift (sync-lifted code has no post-return execution window, and pre-return writes deadlock — streams are unbuffered rendezvous). Suites capable of that are exactly those for which concurrency tolerance is plausible; the sync long tail structurally cannot claim it falsely.
• Backpressure becomes the suite's pacing valve: a concurrent runner floods run calls; the suite bounds admission via backpressure.inc/dec. Guest-controlled max-in-flight, no protocol addition.
• Note: intra-instance concurrency is cooperative-only (no parallelism until shared-everything-threads) — it overlaps host-import latency only. Runners wanting throughput should replicate suite instances and partition cases, which works today under the sequential baseline and gives isolation for free. This interface is a latency optimization for I/O-bound suites and an enumeration-overlap enabler, not the parallelism mechanism.

Constraints

1. tests stays mandatory. This interface is strictly additive; every suite exports the sequential baseline (SDKs emit both from one table).
2. Selection is composition-time, not runtime probing. World imports cannot be optional, so a runner core importing concurrent-tests cannot link against a plain suite. The CLI/composition step (component-test CLI: compose via wac-graph, not wac script + binary #19) inspects the bundle's exports and selects the sequential or concurrent runner core; native/host runners may probe dynamically.
3. Deferred design costs attach here, quarantined from the frozen baseline:
   • trap attribution under concurrency: a trap poisons the instance with N-1 cases in flight — neither pass/fail/skipped/not-applicable; needs a new L4 status (abandoned-by-co-tenant) and attribution rules (the trapping case may be a victim, not the culprit);
   • interleaved diagnostics ordering across concurrent contexts;
   • whether concurrent runners must still support per-case timeout-abandonment semantics.

Context

Grew out of two separate discussions: relaxing the sequential-execution default (guest-side opt-outs via sync-lift/backpressure are real but invisible to runners, so a declaration is needed — and interface presence is the best declaration), and streaming enumeration for dynamically-constructed suites in interpreted languages (rejected for baseline all(): lazy per-case materialization captures most of the overlap benefit, and returned-stream production is async-lift-only).

Blocked on nothing; deliberately deferred until a suite demonstrably needs it.

[lann]

Adapter analysis — this interface is bidirectionally adaptable to/from the baseline, which strengthens the composition-time-selection story:

• concurrent-tests → tests: adapter drains the enumeration stream to a list and exports its own wrapper test-case resources (forwarding name/run, re-lending the context borrow — no resource-identity issue). Sequencing is free: a sequential runner never overlaps calls.
• tests → concurrent-tests: adapter wraps the list into a stream and serializes overlapping run calls behind an internal async lock — an adapter can impose sequencing on a concurrent runner (degrading performance, not correctness).

Consequences:

• Constraint 1 (every suite exports both) can relax to baseline or adapter-inserted: SDKs may emit a single implementation, with the CLI (component-test CLI: compose via wac-graph, not wac script + binary #19, wac-graph) inserting the appropriate adapter at composition time. Runner cores need no variants — each targets one interface.
• This analysis caught an L1 flaw in time: all was sync-typed (func), making the collecting adapter unimplementable (blocking on the inner stream read in a non-async export traps) — along with any dynamically-constructed suite whose enumeration blocks. Fixed: all: async func() -> list<test-case> (async doesn't color; sync implementations remain legal). General lesson recorded: adapters between the baseline and any suite-side interface must be expressible is a good litmus test for baseline signatures.