Virtual time in unusual circumstances

I was experimenting with $timeScale recently to do slo-mo, and noticed that the game clock continued to run at the same rate. Well, the game clock uses getVirtualMilliseconds, so one would think that it would correctly track any monkeying with the game's timescale, but nope.

If you look in main.cc, you can see where the "virtual time" is incremented using Platform::advanceTime; it looks like this:

U32 timeDelta;

   if(gTimeAdvance)
      timeDelta = gTimeAdvance;
   else
      timeDelta = elapsedTime * gTimeScale;

   Platform::advanceTime(elapsedTime);

And then timeDelta is used to advance the physics simulation and trigger scheduled events. So the timescale does affect those processes, but it doesn't affect the virtual time. I tried fiddling with that so that the virtual time is also affected by the timescale, and that fixes the clock behavior, and the game seems to work fine, but I'm a little nervous about that. I do see a lot of uses of getVirtualMilliseconds throughout the code that make sense in that they should be dealing in "simulated time" (for example, the progression of changing light color in sceneObject.cc) but also a lot of other uses that seem to be expecting "real time" (for example the calculation of ping time in netConnection.cc). Although, granted, most or all of those latter uses are in the net code, where it probably doesn't matter for any practical situation where you would be changing the timescale...

The other monkey wrench in the works is $timeAdvance, or gTimeAdvance. Looks like this is supposed to roll the simulation forward by a fixed time period, but again, it doesn't affect the virtual time.

I'm inclined to think that a) it's an oversight that timescale and timeadvance don't affect the virtual time, and b) that there are uses of getVirtualMilliseconds in the code that should be getRealMilliseonds instead. But I ain't sure. Thoughts?