For the bridge, my thoughts were that it would be possible to trick the drupal module into thinking it's being called by drupal ecommerce - it would only use the documented ecommerce hooks. In other words, a 'bridge' module would effectively just be an API proxy - ubercart calls its hook method, which in turn calls ecommerce's hook method. Unless the APIs are so radically different..?

I can see the reasoning behind dimensions, but at the same time, it's something that PROBABLY isn't going to change for a given product based on the shipping carrier (aside from "standard" box sizes).

In theory you could actually figure out what standard box sizes to use based on product dimensions - but in reality it is much more complex and possibly not worth the effort (think: irregular-shaped objects: eg, a wedge of cheese requires a 4x4x6 box, but you can actually fit two in one box).

This is probably worthwhile sorting out, and I'm willing to put some effort in - since I'm going to need to deal with dimensions one way or another (writing a canadapost module, or a bridge).

My suggestion is moving the dimensions to the product module, then we can figure out more complex calculations from there.

For example, "maximum total space per box is X CuFt/cm3" to calculate how many separate boxes a shipment has. Maybe a size reduction multiplier in the product, eg "For every X of this item/item in this category/product class/.. reduce space usage by Y%". I'm not suggesting implementing this stuff now, it's just nice to have an end goal in sight when planning design changes.