>more time spent working on the problem by a domain expert gives more opportunity to identify deficiencies in the specification

So much this. This is happening in other industries, too. Domain experts are also becoming less expert because of lack of proper feedback about their designs.

It's great to have a spec, but you should understand what's happening with the spec and how it applies to the actual code that executes.

With software we can get software that is very close to being an executable spec. By adding a layer of indirection we make everything harder.

Developing Safety Critical Systems is nothing like developing "ordinary" systems. The stakes are so much higher that absolute rigour at every step is demanded and enforced. This is why "Software Engineering Process" methodologies were invented and enforced using "Formal Methods". When this rigour is lost you have catastrophic system failure like in the "current-day" Boeing company.

> Never mind that this idea of an offshore team diligently implementing the spec to the letter hand-waves away the software engineering, as if it’s a mere implementation detail not intimately connected to the system delivering the desired safety and performance characteristics.

If the "offshore" team does not have the requisite Domain Expertise (which seems to be the case here), then it is Boeing's job to provide rigorous specifications and more importantly have safety checks/verification/tests/etc. in place to guarantee "correctness to spec." Problems in the specifications itself are the responsibility of the Boeing Design/Engineering team.

You have missed the point.

Domain Expertise is an absolute necessity to come up with Rigorous Specifications and in particular; for Safety Critical Systems.

If they can be done by a single person (whatever be his role name) all the more better but usually for Safety Critical (and highly specialized) Systems that is not possible and hence you need two (or more) people.