The answer to this is yes, we had to convert the package to SQL 2012 format. For now we keep our packages in SQL 2008 format in source control, and at deploy time migrate the page to 2012 format. Once done, the performance is on par.
Yes, this is how it works: You lose the updates that were made in any CUs not included in the service pack (sometimes it is more than one CU that is "lost" temporarily).
And no, you can't then apply a Service Pack 1 Cumulative Update to Service Pack 2: the installer simply halts and won't let you do it.
The reason it works this way is that the Service Pack code goes through a longer and more rigorous testing cycle, so needs to be "locked down" months before release, unlike Cumulative Updates which go through less rigorous testing in their - typically - 8-week cycle.
While the SP is being tested, issues continue to be discovered, fixes continue to be checked in, and Cumulative Updates continue to be released. The world doesn't stop because a Service Pack is being tested.
In no situation that I have seen has an SP cycle been halted so that it can include a fix for some issue that has been discovered in the meantime - depending on the nature and severity of the issue, they may "fast-track" a post-SP CU, or they may issue a separate on-demand hotfix. I've seen both of these scenarios happen (more below on the latter). Typically, though, the first CU after the SP was released includes all of the fixes from the last CU or two from the previous branch, kind of a "catch-up."
So, please, wait for Service Pack 2 Cumulative Update 1 (should be end of July, according to this post) before installing Service Pack 2, or be willing to lose the fixes in CU #10.
(And in either case, if you are on Enterprise and run your rebuilds online, please see this blog post about an IMHO critical hotfix addressing a data loss/corruption issue.)
Best Answer
No. Each CU contains all the fixes in the CUs prior to it.
For the second part of the question, the only RELIABLE way supported across most versions (2005+) is to get a 4 part number and compare it to any of the comprehensive build lists available on the internet:
You can also check @@Version but it's not reliable, as some older CUs don't list their CU number as they were meant to. You can also try Serverproperty('ProductUpdateLevel') but it's only supported on a few newer versions and service packs of SQL Server.
So I stick with build numbers. Most DBAs have one script or another to pull data from web sources into a table to do translations.
If in doubt start the CU installer and it will check whether it's needed or not. It won't let you continue upgrading if you've already upgraded everything on the server.