> Should I make use of a single logger object in my library, multiple loggers
> in a tree, or multiple unrelated loggers? Since I have just one public module,
> I'm tempted to say that I should just use one logger object.

Yes. The advanced logging tutorial (part of the HOWTO) states:

"A good convention to use when naming loggers is to use a module-level logger, in each module which uses logging, named as follows:

logger = logging.getLogger(__name__)

This means that logger names track the package/module hierarchy, and it’s intuitively obvious where events are logged just from the logger name."

This seems clear enough to me. Did you look at the whole of the HOWTO? If not, I'd advise you to take the time

> (The documentation says "No handlers could be found for logger" 
> spam only happens pre-3.2, but some of my users at least think
> they see it in later Pythons.)

In 3.2, the change was made to introduce a "handler of last resort" instead of the "no handlers could be found" message, which is only printed if logging.lastResort is set to None or other "false" value (by default, it's set to a console handler at WARNING level emitting to sys.stderr). If you can give specifics of a later Python version where this happens (precise Python version, OS etc.) then we can address it.

Practices vary widely because use cases for logging are widely varied. A simple one-off script has different needs from a product with a long shelf-life, a command-line application has different needs from a long-running server application, a single-author application has different needs from one which is put together from lots of different dependencies by different authors, etc.

> Why should a Logger object need to have .basicConfig() called on
> it after retrieval (where "retrieval" means "getLogger call") and
> before use anyway?

It doesn't. If you want output, you need handlers. The basicConfig() API is just one way of attaching handlers to loggers for simple use cases. The question of handlers is also no concern of a library author, other than the NullHandler part, as the application is where logging should be configured (as mentioned in the "Configuring Logging for a Library" section).

> Then we could establish the "gold standard" for logging and write
> about it in the HOWTO.

There's no one size fits all, I'm afraid, because the package is designed to cover a wide range of use cases, not just the simplest ones. While there is (IMO) comprehensive documentation, specific proposals for improvements will be looked at constructively.