Well, you are not nitpicking, no. It's just a fundamental question of what should be a table vs what should be a query. Or perhaps how should we treat a table returned by a query when it is used as a base of a component.
Here's the current logic:
If a table is static, or, more specifically, if only one instance of its records exists (in the case of an external database, on a server), then we treat that table accordingly. That is, if you view that table as a drawing in some window and select some records, that selection persists. If you then close the window and reopen it, the records will still be selected. If you open a different window showing the records of that table in some other way, some of those records will be selected there.
If a table may have multiple instances of records, eg, because it is dynamic = computed on the fly, then we treat it accordingly as well. If you view that table, we create an instance of its records (instance 1). If you then view that table in a different window, we create a new instance of its records (instance 2). We assume that the records in different instances might be different as well. In the case of a query that might be because the text of the query has changed, or because the data in the queried tables has changed, or because nothing has changed but the text of the query includes things like "let's look at all records for the last 2 hours" and the current time has changed. (As an aside, we agree that in the case of materialized views, records are actually stored on the server and there is only one instance of them. But a materialized view is still closer to a view than it is to a table, because it still has the text that can be changed relatively easily, so we treat it as a view.)
In general, we can limit tables returned by a query to a single instance. Maybe that's a better approach. If you change the text of the query, you would still be able to recompute the table using View - Refresh in the table window, etc. If you make changes to the underlying tables (eg, add some new records) and want to recompute the query after, same thing, manual refresh whenever you want. If the text of the query depends on the current date or generates random values, same again, manual refresh. Then we can share the selection. Do you think that would be better?