Hi Sebastian and thanks so much for your feedback :)

1. So with observation an `ObserverContext` is created when using a store in a component. This "ObserverContext" tracks what signals you access in the component. This "ObserverContext" has to end its tracking when the component function exits. This is what `using` does. It runs logic when the component function exits to stop tracking signals. Then indeed we run a `useEffect`, or rather `syncExternalStore`, subscribing to the `ObserverContext` created. Traditionally you would have to wrap your component function in a higher order component, but then you have an additional import and you have to define your components as variable assignments. This also affects debugging as your components are typically not named with this signature. So yeah, think of `using` as "tracking signal access in the component scope" :)

2. So until now I have not been in a scenario where you would need to do this. Either you use a "key" on the `StoreProvider` to unmount and mount with new props. Which makes sense if the prop for example represents a user or a ticket in a project management app. Typically subscriptions created internally in the store would be its dynamic nature. That said, this does bring up a very interesting idea. We could make the props signals. So you would access the props in a store like any other signal you define in the store. I need to reflect a bit more on it and create a POC, but it is something we should implement before the official release as it would be a breaking change later. Thanks a bunch for this perspective!

3. A bit of text was lost there, but as I understand you suggest giving first class support for traditional Observables in signals? And you mean RxJS types of observables? I did reflect on this early on. Like Angular has a `toSignal` on their observables. This is something that can easily be added later given that we find a good way to execute on it. I'll experiment some more on this, thanks for bringing it up :)

4. Impact is considered a much lower level API than traditional global state management. So if you want to synchronise a signal with a url or local storage you would currently have to do that manually. But as a lower level API I hope to see people build abstractions. For example there could be a local storage sync API that looks like:

``` function MyStore() { const count = signal(0) const flag = signal(false)

  syncLocalStorage('$SOME-KEY', { count, flag })

  return {
    get count() {
      return count()
    },
    get flag() {
      return flag()
    }
  }

} ```

In this case the `syncLocalStorage` would be a two way sync with local storage. You define the initial signals and then any changes to them will be synced to local storage. Any changes in local storage is synced back to them, including any initial value. When the store unmounts, the sync is disposed of.

But yeah, I am not sure to what degree these things should be added to the library (It adds maintenance cost which I have been hurt by before). I want to first see if the community sees these opportunities and creates abstractions :)

Again, thanks a bunch for the feedback, I hope my responses made sense and have a great day!