OK, I checked the code (way more accurate than empiric tests), and it is NOT a balance change that triggers the interest but any operation that involves HBD.
Any operation involving assets call function(s) (database::adjust_balance() which calls database::modify_balance() for liquid, or database::adjust_savings_balance() for savings) which will do the interest payment if required, whether the balances really change or not.
Even cancelling a withdrawal from savings can trigger an interest check and potential payment.
So it's better to tell people that any operation involving HBD could trigger interest payment!
Ah, speaks the overly-confident programmer :-) While I agree that code inspection plays an important role in determining in full how code is intended to function, it's my experience that empirical testing is also a vital part of determining actual functionality. And if I have to rely on just one or the other, I'm much more willing to trust empirical tests.
That's overly broad, IMO :-) Consider a hypothetical operation that changes the time period for which funds are staked. Such an operation would have no reason to call adjust_balance(). On the whole, I think that the best description is still that operations that change the balance are the ones that are intended to trigger interest payments. It's really only a current implementation detail that results in calls to this function even when the balance isn't changed (ie. when the delta parameter value passed is 0). And it's easy to imagine a future where the call immediately returns after checking that value, before triggering an interest computation.