what are you locking here?
It's preferable locking in scopes to make this clear:

{
  std::unique_lock<std::mutex> lock(frame_mutex_);
  // ...
}

I.e. could you validate w/o locking?

This line is in the original, it's locking reading of the tf frame tree until the end of the function, for validateFrameId and canTransformNoLock. It shows up as a new line here because it was moved a few lines up.

Is there a risk of validateFrameId to call back canTransform? If we expect a lock to be held before validateFrameId is called, shouldn't it be validateFrameIdNoLock to align with canTransformNoLock?

It's not that validateFrameID has to have a lock held, but that we are pinning the two validation calls to the same version of the tf tree by acquiring the lock. This doesn't seem to be done in all places where two frames are looked up and then have their transforms checked, and the tree walk happens based on a TimePoint, so I don't think it's necessary. My next version only locks for the tree walk itself. Uploading momentarily

The new version looks better to me.