Caching node tokens by nid causes wrong token values for node revisions

Context:
I'm using the notifications and messaging modules to provide users with a digest of node changes, taken from the node revision log (using the [log] token). However, when multiple updates to the same node are included in one digest message, the token values are always taken from the first (oldest) node revision, so the same log message is wrongly repeated several times.

While this is partially because of a notifications module problem (I'm posting an issue there too), contributing to this problem is the fact that the token module caches node tokens by nid in _token_get_id(). Even when I patch the notifications module to properly pass the appropriate node revision object for each node update event, token_replace_multiple() caches the tokens on the first call and then never updates them because all the revisions have the same nid.

I'm proposing to use vid instead of nid. For most uses this shouldn't matter because only the last revision is used and will be cached properly. If different revisions are passed then they should not be all cached together anyway. In the attached patch, I'm checking if vid exists and if not then it's using the nid as today, so this should not cause any errors in cases when the vid is not there for some reason, and at worst will cache the node twice (once with the nid and once with the vid).

There are a few issues on token caching problems, and I realize that cache clearing is now exposed in the API so could be used by notifications/messaging. However, as stated in those issues, it's much preferable for a module to manage its cache internally instead of asking it's users to do so. In this case, I think the token module can do a better cache management job without hurting performance.

Thanks for considering this.

Micah