IMO (a subset of) pytest is the superior unit-testing framework. Just having functions prefixed with `test_` is easy and intuitive. It also works well with xdoctest, but I would use it even if that wasn't the case. (That being said, I think the current implementation of fixtures - where you can't easily make an instance of the object outside of the pytest framework - are an anti-pattern, and I will die on that hill).
As for logging, I would love a redesigned logging module. The main issues I have with the current one are: (1) I don't like being forced to put logging initialization at every entry point in my program/library, I wish there was a better way to do that, even though I can't think of what that is. (2) When I do enable logging I often get junk from other libraries using it that I don't need. (3) I want first-class support for instance-level logging objects that belong to a specific object instance, this can sort-of be done with the current interface, but it's a bit clunky.
But as to the original intent of this post, I agree with Stephen Turnbull that foolish pep8 consistency is not a big enough reason to touch the stdlib. And honestly, a better logger would likely be best handled by a third party library, at least for the initial phases of its development and field testing. If it got wide acceptance and was simple enough, perhaps making its way into the stdlib could be considered. But I don't think a good alternative even exists right now.
There is something to be said for replacing unittest with a better no-third-party solution, and I think pytest is a bit too big to bring into the stdlib. But perhaps a subset of it (pytest lite?) might be isolated and considered for inclusion down the line?