One of the main goals of this project was to create a significantly simpler interface that is more aligned with other Rx implementations, offers a richer concurrency model, offers more optimization opportunities and is more aligned with built-in Swift error handling mechanisms.

Probably the main difference between these projects is in their approach in building abstractions.

One of the benefits to representing all of these abstractions as a single concept - ​observable sequences​ - is that all computation abstractions built on top of them are also composable in the same fundamental way. They all follow the same contract and implement the same interface.
It is also easy to create flexible subscription (resource) sharing strategies or use one of the built-in ones: share, , publish, , shareReplayLatestWhileConnected…

Multithreaded programming is really hard and detecting non trivial loops is even harder. That’s why all operators are built in a fault tolerant way. Even if element generation occurs during element processing (recursion), operators will try to handle that situation and prevent deadlocks. This means that in the worst possible case programming error will cause stack overflow, but users won’t have to manually kill the app, and you will get a crash report in error reporting systems so you can find and fix the problem.