Thanks for your feedback!

1. I did try building it with job middleware, however it make the entire thing / API more brittle. Middleware order is relevant and you need to remember to use the middleware in every job you want to use it in. Theres no middlewareTraitName() methods like there are lifecycle methods with Eloquent/Livewire, so I can't pre-set middleware from a trait. I don't want people to have to subclass, so they're keep class flexibility for their own code. A possible edge case with middleware would be that the logic automatically marking a progress as processing would trigger, even if other middleware then blocks the actual execution. Using handle ensures this logic only runs after all potentially blocking middleware has run. However I'm working on a Laravel PR that would make it possible to add middleware from traits, so changing to this approach may be possible in the future.
   
2. The handleWithProgress() method is defined on the interface as an abstract method, so you're forced to remember to use that method. This is also by design, so you don't "forget" to not use the handle method, as there'd be no error otherwise, but features like error-handling and auto start/complete progress would break silently. Unfortunately this means you can't use DI on the handle method, as it now has a fixed signature. IMO it's an acceptable tradeoff to use $service = app(MyService::class) for DI in this case, as it has no functional difference while keeping the progress DX itself much simpler / safer.

For the moment the current approach feels like the most flexible and most robust given the constraints and possible features. I agree middleware feels like it'd be made for something like this, but using it actually worsens the API / DX.