As an Android dev, I find that I/O often has negative value to the developer, and none to the users. Anecdote: I tried to implement Paging3. First, the archite

As an Android dev, I find that I/O often has negative value to the developer, and none to the users. Anecdote: I tried to implement Paging3. First, the architecture was quite rigid and did not fit the way we handled our data. We spent days modifying the data and every component related to fit Paging. After all that work, we got it to work, only to find a "To do" error when using String IDs as pages as opposed to incrementing an integer. Also if you had invested time into learning Paging2, you'd have to throw away all that effort with Paging3. The more recent Material 3 is sexy, but the "easy" tools introduce a lot of ugly imperative boilerplate into my theme code. It smells hacky, as if it was not properly designed for this use case. So my impression is that I/O is really just there to get alpha/canary testers.