Hm, puzzling one.
Part of this is easy to explain -- the tempo tracker is indeed supposed to return a result only when the tempo changes, as documented, but the current release has a bug that makes it return a value on every process call whether it has changed or not. This has been fixed for a while in the code repository and will be fixed in the next release (not too far off I expect).
The discrepancy in tempo and beat timings is harder to explain, and I'm not sure I have the requisite knowhow to completely understand what caused this. I believe that there's no intrinsic built-in guarantee that the tempo and beat timings will match up with one another, because the tempo is an underlying estimate that covers a relatively lengthy period while beats may be fitted to track local changes somewhat. Also, both tempo and beat locations have a limited resolution essentially based on the internal frame size -- as I understand it, 115 and 117 are actually rounded versions of two immediately neighbouring values at the internal resolution (so this may be a simple off-by-one error internally, or it may be something subtler that is not technically a code error at all).
It may be helpful if you could link to audio data to go with your results (I realise this is not always possible).
If I get any more information on this, I'll add it!