The current behavior is the quick and easy/dirty solution that we have, not what we especially want.  #27609 has multiple issues and ideas for completion improvements.  I made testing and improving the code priorities before worrying about most of the proposed changes.

Here is where we got confused a bit.  The title refers to shell completions.  The opening post starts with shell completions and then moves to intended behavior for editor completions and its dependence on the presence of a shell.  I disagreed with the latter and responded, not thinking much about shell completions.  Lets stick to shell completions, at least initially (and change the title if we include editor completions).

Tal: "Perhaps we should differentiate between completions in the shell vs. when editing a file."  I agree that we can consider adjusting the list according to the setting.  It is easy enough.  Open_completions, executed in the idle process, can detect whether the associated text is the shell or an editor and pass a (new) flag to fetch_completions, which will pass it to the fetch_completions executed in the run process.
 
Tal: "In the shell, having completions for things not actually available is weird".  That I can see and agree to. While the editor allows after-completion revisions anywhere in the file before running, the user cannot revise Shell history and insert an executed import before executing the current statement.  A doc statement like "Name and attribute completion in the shell is restricted to names and objects available after previous shell statements." seems clear enough to anyone who reads it.

As near as I can tell, both before and after the #21261 patch, name (tab) completion *is* restricted to valid names.  But attribute completion will complete for modules such as socket import by run.py even when not in the main namespace.  Python in masOS Terminal (bash, I believe) does attribute completion (.<tab>), but only for user visible names, not, for instance, for reprlib.  The proposal is to restrict IDLE's Shell's attribute completion similarly.

Tal: "I really dislike the arbitrary availability of only certain modules for completion."  It is not completely arbitrary.  We could complete stdlib names from a pre-generated list.  But that would add perhaps 400 names to the name completion list.  But we can only complete attributes (which I, at least, use much more) for modules in sys.modules. A possible improvement mentioned more than once is on-demand import, at least of stdlib modules.  If any are shown to be a problem, we could make a blacklist.