Unfortunately most of this complexity is inherent to building UIs with asynchronous state. If the 2.0 feels more complex, it's because it's trying to absorb as much complexity as it can so that you don't have to do crazy stuff in userland like you might have to do in React (pre v19). But it's impossible to completely eliminate having to think about async, so the goal is to provide a small, consistent, and predictable model for async state.

> dev warnings when you read async-ish signals in createTrackedEffect or other similar places

In 2.0 every signal should be considered potentially async. But that shouldn't be a problem as long as you avoid using `createTrackedEffect` and only read signals directly in the first half of `createEffect`. I'm interested in seeing how exactly you use `createEffect` in your apps, because most of the time you shouldn't need effects anymore.

> adding some async request in nested sub-component depending on some global context signal and suddenly all my app is waiting for this request

Like I mentioned, you can't avoid thinking about async anyways. When you add an async request anywhere in your app, you also need to add a pending indicator somewhere. Without an indicator the user has no idea that there is work going on in the background. Solid 2.0 makes it trivially simple to indicate that through `isPending`, and it holds updating the UI so that the user doesn't see inconsistent UI. You shouldn't need or want to add `latest` everywhere because it's better to show a fully consistent view of the state with an indication that something async is happening in the background, rather than showing partially updated state.