Orders use shipping ID with SKU added?

Every other shipping module uses the shipping method ID and shipping service ID to store shipping details for an order:

* fedex / fedex-2-day
* fedex / fedex-ground
* ups / 07
* ups / 12

And even flatweight does the same, using "[machineName]" and "default" as the service ID:

* zone-1-2 / default
* zone-10 / default

These IDs are static and discoverable and available via getServices() - you can always work backwards from "what they mean". This allows us, for example, to provide a translation layer to a local warehouse - when we know that the user has chosen FedEx Ground (because the order's shipping information is stored as fedex / fedex-ground) - we know that we can turn that value into the warehouse's custom mapping of "FEDEXGROUND" (for example). We rely on the same approach for UPS and all other shipping methods...

BuUUut, the new USPS API, and the current Commerce implementation, doesn't appear to do this. Whereas before we could check getServices() to get values of usps / 1 or usps-international / 2, the values are now appearing to save with a SKU, becoming something like 3 / DMXX0XXUR00010. Since these SKUs appear to only ever show up during rate calculation, we also can't provide a translation layer UI for admins to fill out during site setup - unless we manually work to discover each and every SKU and provide a hardcoded table (vs., in the past, using $shippingMethod->getPlugin()->getServices()).

Is there a problem with using mailClass for the order internals? Even using it IN ADDITION to the SKU would be more helpful than just SKU (i.e., something like "3-MEDIA_MAIL-DMXX0XXUR00010" would allow us to substring match...