it would be easier to discern the objects and tables in a query if you are revisiting the query after a time away from the project. Another use case would be if you have shared a project .map file or have stored a query in a enterprise datastore.
I agree, of course, that there would be some utility for that. Now, as a though experiment I ask you to write out all the scenarios in which that might be used, how it could go wrong, and what the system should do about that. I'm not asking you to program it, I'm just ask you for a clear and complete thinking through of what you propose, so you actually propose the thing beyond a vague notion stage.
For example, by "persist" I suppose you mean that it is stored in the .map file, so that when you open that .map project you get a neat re-filling of the query builder with all the tables and fields and such as it was, right?
Super. So now you give that .map to a colleague on a different machine in Argentina and he or she opens it. Ain't no such data sources on that different machine. What happens? Is the pane full of tables and fields empty? But you've already advised the colleague that it is persistent, so what does that mean when it is empty? How is the colleague warned?
How about if you just move the project within your own hierarchy and now the absolute paths to the data sources are incorrect. What then? Suppose you've renamed something in one of the data sources. Is the query builder suppose to recurse through all projects on your computer and the billions it can reach through your network connectivity to update any changes that were made since the last time the project was opened? If it doesn't what it shows in the pane is wrong and misleading. Is that OK? Should the user be alerted somehow it is wrong and misleading?
All this is part of thinking such things through. It is not in any way intended to ridicule what, really, is a perfectly appealing desire. It is intended to open up the consideration of what goes into such an apparently simple notion. Each and every such question I raised above and the (probably) hundreds of other similar considerations that go into such a notion is absolutely, guaranteed possible to do. It all can be resolved into a very smooth implementation.
But the question is, at what cost, and for what benefit. If the benefit is slight and the costs are huge, are there other areas in which the resources should be applied first?
I don't mean that to discourage new ideas. But, as part of any new idea the next step after initial utterance of the thing is to dig deeper and to do the thought experiment to ask yourself "How would this actually work in practice..." so you can specify the detail of what you want. You have to do that anyway, so may as well do it at the beginning to know if a) maybe there are better ways to get what you want, and b) maybe the whole set of issues involved is not worth the benefit it brings.