Ok, the jump occurs because the overlay code has changed the volume and the player isn't aware of this change. The player keeps tabs on what it *thinks* the volume is and doesn't read what it *really* is before changing it. (We could consider this a player bug, but there may be reasons for this...) So any volume change in the kernel must be kept hidden totally from the player, hence the reason that the volboost code is written the way it is.

What is interesting is that the overlay code appears to use a non-volboost compatible method of lowering the volume, which is why we don't see the debug messages when that happens.
But when it raises the volume, it appears to use a method that is volboost compatible - hence the messages. This disparity needs to be addressed to avoid sending volboost nuts.

The test has also told us that volboost itself isn't causing the issue - something is explicitly asking for a volume level of 85, and volboost isn't adding anything of it's own. BTW, that means row 85 in the volume table, which should be about -2.5dB IIRC. (row 90 is 0dB)

[edit]
Ok, I've just re-read your post more carefully, and you allude that the patch does raise the volume correctly to start with, and the jump is an additional volume change.... let me go read the patch.