> 2. it is clear about what becomes ineligible (AFAICT, it's a Participant)

This should be made clear through naming, yes. However, it's not an argument for one architecture over another. (It's actually the person which is being marked ineligible.)

> 3. it avoids explicit runtime modification of classes (which can be slow, and interferes with JITs)

Agreed, the runtime class modification is not necessary. I'm not sure what it is trying to achieve, but certainly a DCI approach does not require it.

> 5. it works for all ResponseSet modifications, not just those occurring in an HTTP request

A DCI approach makes this logic available to all places where you need to make a Participant ineligible, not just those resulting from ResponseSet modifications.

Invoking the context from an Observer is probably a good idea, so long as it is idempotent. I can't think of a reason why it couldn't be.

> `person.participant.ineligible!`

Marking a person as ineligible affects models of several different types, including creating a `SampledPersonIneligibility` and removing the associated `Participant` and all its relationships everywhere.

One of the actions that happens when a person is recorded as ineligible is that the participant record itself is deleted. I think it's awkward to have that action be on the participant. This logic is also PBS-specific, so binding it to the generically-named method `ineligible!` on `Participant` (or `Person`) doesn't sit right.

> DCI has its merits, but mixing it with existing code that doesn't follow that pattern requires that it offer a very large payoff and I am not sure what that payoff is.

From a higher-level view, we have lots of places where there is logic which applies to several models in concert that is arbitrarily associated with a single model. It's often hard to locate the logic that applies to a particular feature. Rails does not have a convention to handle this, AFAIK. DCI provides one way, so I asked Steve to try it out here. 

I think you've identified some problems with the implementation, but I don't think that any of them apply to the general idea of using DCI.