Brenton Simpson

This broadly sounds good to me. Here are specific areas that may need clarification: ## Streams ## I understand the desire to have `enable()/disable()` methods in L1 APIs - most...

> Our documentation will introduce enabled/disabled as the mechanism by which you ensure that an interaction becomes generally-reactive. Pausing an enabled interaction will not stop it from being reactive, though...

> To be clear, properties may not change the behavior after it's been enabled. E.g. changing the gesture recognizer for an interaction after it's been enabled may require that you...

(I'm presuming the transition example is iOS only, so I'm not concerned about it.)

👍

The reason that the official `Observable` implementation has a `complete` channel is to alert observers that they are going to be forcibly unsubscribed. This means you can call `headSubject.complete()` and...

The purpose of a library should be to do the hard, tedious, or non obvious parts of an implementation for you, especially around security. This is why I believe we...

I believe my proposal meets that requirement in the spec. My reading interprets the cookie as an example of what to hash, not a requirement. We could allow the user...

That sounds good to me. I'm trying to spend more time on core functionality in my app right now, so I probably won't be submitting a pull request any time...

That looks about right. You can see my implementations here: - [`MemorylessIndefiniteSubject`](https://github.com/material-motion/material-motion-js/blob/develop/packages/core/src/observables/MemorylessIndefiniteSubject.ts) - [`IndefiniteSubject`](https://github.com/material-motion/material-motion-js/blob/develop/packages/core/src/observables/IndefiniteSubject.ts) As you can see, I've separated the caching behavior from the observer pooling. Looks like you...