In RTK query, your query can be more complicated than just a single fetch, so you could choose to implement this as one query and use a selector to pull out the values that match your search.

But I'd probably just implement this as 2 separate queries and do the concatenation and filtering as a useMemo right there in the View, with the loading spinner depending on isFetching from both queries. I'm still working out in my own head how to deal with the coupling this convenience brings (once you have a couple of mutations going on, you wind up with your View directly tapping into a lot of hooks).

In the old days, I'd have used Sagas to manage the side effects. Sagas were easy to step through (so much so that one method of testing was just to drop expected return values into each next() directly), but I do feel that this hole in Redux comes from the way React in its early days punted on the hard problems itself, and Dan chose to punt on side effects. You could argue that he left the door open for you to choose a strategy yourself, but I don't think the React community as a whole has benefitted from not having an official way to do things in the beginning. Nor having an official (but crap) way to do things now.

I guess my position is it's great to have a FW be opinionated if the opinions lead the developers who use the FW to be better engineers, but it's terrible if it encourages them to be worse engineers.