[yuppie]
... Don't know what other people think. I believe restoring the old undoInfo behavior and adjusting the documentation would be the best solution. Fixing this in undoable_transactions would fork the behavior of both methods and fixing all products that depend on the old behavior would cause unnecessary trouble.
Can you document the behavior you want? Because there were multiple bugs in the implementation before, I'm not exactly sure what "old behavior" was in all cases; I'm certain that _some_ of it was purely accidental, never intended, and utterly surprising (when last < 0). ZODB/interfaces.py's IStorageUndoable.undoLog documents the current behavior, which matches what ZODB's UML docs have always claimed behavior should be. This behavior is tested in ZODB too now, so any change here requires fiddling code, docs and tests. If Zope requires particular behaviors, it should grow tests for those too. I'd be happy enough changing `first` and `last` to act like Python slice indices instead, with the caveat that because there's other weird non-Python behavior mandated when last < 0 (then undo{Log,Info} are documented as taking the absolute value of `last` as being an upper bound on the # of results to return -- and "old behavior" was related to that, albeit with bugs of its own), they cannot act like Python slice indices unless `first` and `last` are both non-negative.