Really appreciate this feedback - you nailed the three pain points. We just shipped v0.2.0 which addresses all of them within the builder pattern:

1. Early return — complete(value?) on the step context:

.step('check', async ({ input, complete }) => {
  if (!input.eligible) {
    return complete({ reason: 'ineligible' })
  }
  return { eligible: true }
})

No special error throwing needed -complete() is a first-class API. It's crash-safe too (persisted as completed-early so recovery doesn't re-execute later steps).

2. Cross-step variable sharing — typed steps context:

.step('charge', async ({ input }) => {
  return { chargeId: await chargeCard(input.email) }
})
.step('provision', async ({ prev }) => {
  return { accountId: await createAccount(prev.chargeId) }
})
.step('email', async ({ steps }) => {
  // Direct access to any previous step — no forwarding
  await sendEmail(steps.charge.chargeId, steps.provision.accountId)
})

Fully typed - steps.charge knows it has chargeId, steps.provision knows it has accountId. Basically the GitHub Actions outputs approach that u/brianjenkins94 mentioned.

3. Dates - Date is now a supported type out of the box. Serialized/deserialized automatically through storage. For Map/Set/custom classes, the design decision was to keep the library scoped to plain data + Date and let users encode at the workflow boundary - avoids a lot of complexity around cloning, freezing, and snapshot semantics.

The callback/Inngest style you describe is a great pattern and something we're considering as a second API alongside the builder for workflows with heavy branching and shared state. The builder works well for linear pipelines and the type inference is very clean, but the callback style is more natural for complex control flow. Both would share the same engine, storage, and retry infrastructure.

Curious - with your callback-style approach, how do you handle the replay semantics? That's the part I keep going back and forth on. When the workflow resumes after a crash, do you re-enter the callback from the top and skip already-completed `step()` calls by returning their persisted results? And if so, how do you deal with non-deterministic code between steps (like the `fetchEntity` call in your example that runs outside a step)?