anchor.diff:                            true ->
                                  true
                          end,
  +    HistoryList = queue:to_list(History),
  +    UniqueHistories = lists:usort(HistoryList),
  +    UniqueHistoryTrigger_p = length(HistoryList) > (?MAX_HISTORY_LENGTH-1)
  +                             andalso case UniqueHistories of
  +                                 [ [] ]       -> false;
  +                                 [ [MyName] ] -> false;
  +                                 [ _  ]       -> true;
  +                                 _            -> false
  +                             end,
       ?REACT({b10,?LINE,[{newprop_epoch,P_newprop#projection_v1.epoch_number},
  -                       {is_relevant_to_me_p,IsRelevantToMe_p}]}),
  +                       {is_relevant_to_me_p,IsRelevantToMe_p},
  +                       {unique_histories,UniqueHistories},
  +                       {unique_history_trigger_p,UniqueHistoryTrigger_p}]}),
       if
  +        UniqueHistoryTrigger_p ->
  +            ?REACT({b10, ?LINE, []}),
  +            %% We need to do something drastic: we're repeating ourselves.  In
  +            %% a former version of this code, we called this "flapping" and
  +            %% would enter an alternative projection calculation mode in order
  +            %% to dampen the flapping.  In today's version of the code, we use
  +            %% the machi_fitness service to help us figure out who is causing
  +            %% the flapping so that we can exclude them from our projection
  +            %% calculations.
  +            %%
  +            %% In this hypothetical example (i.e., I haven't witnessed this
  +            %% actually happening with this code, but it's a valid scenario, I
  +            %% believe), with a chain length of 7, during an asymmetric
  +            %% partition scenario, we could have:
  +            %%     f suggests       : upi=[b,g,f] repairing=[c]
  +            %%     c,b,g all suggest: upi=[c,b,g], repairing=[f]
  +            %%
  +            %% The projection ranking and UPI lengths are the same, but the
  +            %% UPIs are incompatible.  In the Git history, very recently, we
  +            %% hit a case very similar to this one.  The fix, after more
  +            %% thought, wasn't sufficient.  A more comprehensive fix, I
  +            %% believe, is using the older "flapping" detection mechanism for
  +            %% this worst-case condition: go to C103, fall back to shortest &
  +            %% safe projection, tell fitness server we're administratively
  +            %% down for a short while (to signal to other state machines that
  +            %% they need to adapt to our bad situation), and then resume.
  +
  +            io:format(user, "\nCONFIRM dbg *************************** ~w UniqueHistoryTrigger_p\n", [MyName]),
  +            react_to_env_C103(P_newprop, P_latest, P_current_calc, S);
  +
           LatestUnanimousP andalso IsRelevantToMe_p ->
               ?REACT({b10, ?LINE,
                       [{latest_unanimous_p, LatestUnanimousP},
  
positive.code: react_to_env_C120(P_latest, FinalProps, #ch_mgr{proj_history=H,
                                                  sane_transitions=Xtns}=S) ->
      ?REACT(c120),
      %% TODO: revisit this constant?
      MaxLength = length(P_latest#projection_v1.all_members) * 1.5,
      H2   = add_and_trunc_history(P_latest, H, MaxLength),
  
      %% diversion_c120_verbose_goop(P_latest, S),
      ?REACT({c120, [{latest, machi_projection:make_summary(P_latest)}]}),
  
negative.code: 
  react_to_env_B10(Retries, P_newprop, P_latest, LatestUnanimousP, P_current_calc,
                  _AmHosedP, Rank_newprop, Rank_latest,
                   #ch_mgr{name=MyName, proj=P_current,
                           proj_history=History}=S) ->
      ?REACT(b10),
  
      P_current_upi = if is_record(P_current, projection_v1) ->
  