Composite synthetic events from EventProjection stage 1: intentional gap or missing pattern?

[ppiela-dev]

I am new to both event sourcing and the Marten framework. My team is investigating building a financial accounting application on Marten. Our initial investigation has gone well, very impressed with Marten, but we are running into a problem building a data pipeline using composite projections. We have constraints on performance and scalability that are moving us to async projections using sql tables. Our choices have resulted in the problem described below. We have investigated several options, but have not found a viable solution. I am hoping that we can get some help from the community to find a better solution or maybe ideas on how to reframe the design problem.

Context. Multi-tenant CQRS service, Marten 8.37. Two async projections in the same domain:

• Upstream (detail projection): EventProjection. Each domain event produces N documents (one detail row per child of the parent entity, e.g. one per period). SingleStreamProjection<T, Id> is shape-incompatible (one-stream → N-docs).
• Downstream (summary projection): aggregates across many upstream rows for a parent entity. Writes a plain-table summary row via QueueSqlCommand.

Both run as separate async shards today. We have a documented cross-shard race: downstream may process an event before upstream has materialized its rows → summary computed against stale upstream state → silent wrong values until the next event for that parent.

What we've validated empirically (test below):

1. CompositeProjectionFor with SingleStreamProjection<T, Id> as stage 1 + downstream IProjection as stage 2 ⇒ synthetic Updated<T> / ProjectionDeleted<T, TId> events delivered to stage 2 ✓
2. CompositeProjectionFor with EventProjection as stage 1 + downstream IProjection as stage 2 ⇒ no synthetic events emitted; stage 2 sees only the raw domain events

Question. Is the lack of synthetic-event emission from EventProjection's ops.Store / ops.Delete / ops.DeleteWhere calls
intentional? Is there a Marten-blessed pattern for "downstream projection consumes upstream projection's materialized output, where upstream is an EventProjection with one-stream → N-doc fan-out"?

Constraints we cannot relax:

• Upstream cannot be made Inline (per-event fan-out is too heavy for batch-style write operations at our scale target).
• Downstream needs to read upstream's materialized state, not re-derive from events (single-source-of-truth principle — derivation logic in one place, no drift risk between the materialization path and a parallel consumption path).
• Solution must not collapse the two into one projection (that path leads to monolithic projections as more cross-projection dependencies emerge in the same domain).

What we've already considered and rejected: merging projections (monolith), re-deriving from event payloads in downstream (drift risk), Inline upstream (scale), polling mt_event_progression from inside downstream (hacky).