The calculation hasn't changed, it's just doing some math regarding the signal wait time and resource wait time. There could be many factors for the difference including hardware, virtual configuration, and even how wait events were classified between the versions.
So, I wouldn't call it a bug, but it is possible that we could have spent time adjusting the query metric for each version and service pack available. If you are having issues troubleshooting a particular issue please contact support so we can help you get to the root cause on that 2008 box.
I had a similar issue that I had attributed to a version upgrade of DPA. The root cause was that the servers with the high Signal Wait % were very lightly loaded and so although the Percentage was high, the actual time spent in Signal Waits was very low, making the high Percentage irrelevant. Adding a chart for the Signal Wait Percentage and the Signal Wait Time (raw) (based on a custom metric) on the Trends | SQL page for a couple of lightly loaded servers and a couple of heavily loaded servers made this obvious.
Of course, you may have an entirely different problem from what I had even though the symptom seems the same.
If you do put in a support ticket, you might want to include a suggestion that the look at the history for Case #854170 before they respond, as it may be related. Support brought sqlrockstar (and others) in a GoToMeeting session to help identify and resolve that issue for me.