Thanks for all this @johndan it looks really nice. I've not really gone through the physics since I think you and @jback have gone through that thoroughly already. So these comments are all more technical.
There are various inline comments (mostly minor). Plus, here are a few general comments:

• Do you have an example of using this generalisation of the K-matrix that could go into the examples dir?
• Please remove the noexcept specifications on functions
  • I would prefer to do a systematic sweep through the package as part of T34 and I still need to fully firm up my understanding of when it is necessary/helpful to do this and what are the prerequisites for it to be valid to do so
  • Having said that, I'm pretty certain that some of those that you've specified noexcept are actually potentially throwing because they call functions that are themselves potentially throwing, e.g. TMatrixD::operator[]
• Please update the release notes

Many thanks @johndan, this looks great. I understand from @jback that he's also happy with this, so I'll go ahead and land this one onto master.

Looks great, thanks Michal!

I'm afraid I don't have time right now to really fully review the physics. But hopefully your tests should have covered that. If we think it's necessary, perhaps we can ask the analysts who were requesting this to do some further validations?
I've added a follow-up on the issue of the various double* arguments - in short I'm also not a fan but let's leave them as they are for now.
I've also added one other small question on initialisation of member variables.
I don't see any other problems.

In D41#1074, @johndan wrote:

General question, @tlatham : should I cherry-pick commits to bring this differential in line with the master (e.g. c38fa2a34f4a772754d1e8f610def10747d95104 - LauFormulaPar fix)?

Thanks for these improvements. They look fine to me.

Thanks very much for this @johndan. It looks good.
I think it would just be good to take the opportunity while we're at it to allow any of the parameters to float.
We should also include the name of the propagator in the name of the parameters so that if we have more than one K-matrix in a given fit we don't get identically named parameters appearing - this will cause problems with the sim-fit for example.
See the inline comments for details.

Many thanks @kreps, looks good to me.

• Update release notes

OK, good to go now, I'll take care of landing it later on.

• Reference Maniphest task in release notes

Hi Dan,

Hi @jback, many thanks for the changes and apologies for the delay in responding to them.
I think this looks good to go now.
Unless @kreps has any comments I think you can go ahead and "land" it onto master.

Hi @jback, sorry it's taken me so long to review this.
You can find here some technical points.
I'll try to compare the physics against the referenced paper next week, although I guess this was checked during the LHCb review?
You mention also testing it using testDecayModel but I can't find the json file(s) for this model. Could you include them in the next revision?

I suppose at least 'worker' should imply someone being paid for their services.

I think the first 3 you list don't really work very well in this context (as you say). However, 'coordinator/worker' describes rather well the relationship of the objects here.
A few alternatives to replace 'master' along the same lines could be 'manager', 'director', or 'controller'.
But I'm struggling to come up with other good alternatives to 'worker', which could maybe still be taken to be a bit pejorative? Maybe 'runner'? Any other ideas?