[BUG?] Client's default options meta is being overridden by fetch/mutation meta

[sergiidiak]

With the migration to v5, I've decided to replace our custom 'wrappers' of query/mutation hooks with queryOptions. The problem is that queryFn depends on other contexts (e.g. custom fetch client), so I'll always need to inject them somehow which is a bit cumbersome to do every time.

I was hoping to use meta for such a dependency injection, but to my surprise, defaultOptions's meta is being overridden by the useQuery's meta option (when set) and not merged with the default as I was expecting. Looking at the code, it looks like a bug to me taking into account that we can augment Registry.queryMeta|mutationMeta and specify an exact type of meta available in queryFn (but not in mutationFn, ref: #7045), but, in fact, you can break the 'contract' by just providing 'meta' in query options.

I've prepared a fix if it is a bug, but if not, would it be ok to add support for merging meta via e.g. query client default options?
I'm happy to contribute to either of the above (also considering to look at #7045 as well)

[TkDodo]

we generally only shallow-merge options, so meta of useQuery is supposed to overwrite meta set globally right now. We could make an exception for meta as it has to be an object, but that would be a breaking change.

[sergiidiak]

Thank you for the reply @TkDodo, is what I was afraid of 😓 Do you think it make sense to add a 'transitional' option meanwhile, that merges global meta with query/mutation meta, which could become a default/made core in the next major release?
If so, I can open a draft MR and continue from there