"""w.r.t. error messages, a regular function that raises AssertionError with a nice message will be precisely as usable."""

sure -- I totally agree -- but that's not the current unittest API :-( where would you put it? How would people find it and know to use it?

"""The reason I'm pushing back on adding methods to TestCase is that every one we add collides with some number of subclasses out in the wild"""

yup -- but again, the existing API :-(

"""
Long term I want to have entirely separate interfaces for these things, but thats even more radical an overhaul than adding matchers as a stock facility, and I don't currently have a planned timeline for starting on that.
"""
that i like -- but yeah, not this week :-). I also think the matchers thing is a nice idea, but still pretty heavy-weight, and it'll be along time before casual users and newbies will latch onto it..

"""
So why can't we make assertAlmostEqual be this? Just add the extra parameter needed with a default value and change the implementation?
"""

That almost sound like your suggesting we actually change the assertAlmostEqual implementation -- that could be disastrous. On the other hand, you could add a relative_tolerance parameter, and if the user sets that, they are indicating that they want a relative test.

I don't like that API: setting different optional parameters to select an algorithm, when you really just want a different function. On the other hand, it does keep us from polluting the namespace, and allows the documentation for them all to be in the same place, increasing the likelihood that it will be found when it should be. 

And if you ask me -- assertAlmostEqual should have had an algorithm like isclose() in the first place ;-) 

It will present an additional documentation challenge. (and a bit of ugly switching code.

Now to find some time to do it -- my sprinting time is done :-(