As I understood the MCO failure, a better type system wouldn't have helped, as the issue was that another program expected metric input while the first program outputted US units.
Units can help verify that a formula within a program is correct (velocity v = 0.5(metric_acceleration)9.8 t;cout<<v.to_metric();) won't compile, for example.
But it won't help with
Program 1:
velocity_imperial v = 0.5(metric_acceleration)9.8 t* t;cout<<v;
The issue wasn't units. It was a break in (programming) "contract". Catching such bugs could introduce further (logic related string parsing) bugs.
A much more robust method (especially considering that this table was prepared in advance) would have been to have someone else to independently duplicate the work and compare results.
That doesn't solve everything. There are still textbooks published that use CGS instead of MKS units. Both of those are metric. Non-SI units are widely used in space (e.g., arcseconds).
Units can help verify that a formula within a program is correct (velocity v = 0.5(metric_acceleration)9.8 t;cout<<v.to_metric();) won't compile, for example.
But it won't help with Program 1:
velocity_imperial v = 0.5(metric_acceleration)9.8 t* t;cout<<v;
Program2:
velocity_metric v; cin>>v; BurnFor(doSomeRocketScienceToCalculateEngineBurn(v))