Asymmetric Behavior of Duplicate Rules on Historical Records

Hi Trailblazers,

I am facing a very specific behavior regarding Salesforce Duplicate Management combined with Before-Save Flows (Fast Field Updates) for cross-object matching, and I would love to get the perspective of senior architects here. 

My setup:

1. Since Salesforce native Matching Rules don't support Picklists for cross-object matching (Lead vs Contact), I implemented a standard workaround. I created a custom text field called Company_Match_Text__c on both Lead and Contact.
2. A Before-Save Flow on both objects copies the value of a standard Company_Picklist__c into this custom text field upon creation/update to act as a text-normalized bridge.
3. It uses an Exact Match criteria on Contact: 
   (Contact: Email EXACT MatchBlank = FALSE) AND (Contact: Company_Match_Text__c EXACT MatchBlank = FALSE)

4. The Duplicate Rule is set to Alert and Report on both Create and Edit.

I have been analyzing two records with the exact same Email and the exact same Company text value:

• Record A: Historical record (created months ago before this Flow/Rule deployment).
• Record B: Newly created record (created today with the Flow active).

The Strange Behavior:

• When opening the new record B, the native "Potential Duplicates" Lightning Component correctly shows: "We found 1 potential duplicate" (pointing to Record A).
• However, when opening the historical Record A, the component says: "We found no potential duplicates".

For Troubleshooting I did the following:

1. I clicked Edit on Record A, changed nothing, and clicked Save. The record saved cleanly. No duplicate pop-up modal appeared, even though B exists with identical data. (However, behind the scenes, the Before-Save Flow ran and populated the custom text field for the first time).
2. I clicked Edit on Record A again, changed the company field to a completely different value, and clicked Save. It saved without alerts (Expected behavior).
3. I clicked Edit on Record A a third time, and reverted the company back to the original value to match Record B. Upon clicking Save, the Duplicate Rule instantly triggered the yellow "Similar Records Exist" pop-up window.

Mi Before Save flow works when a Contact record is created o updated.  

To give you more context on the Flow logic, the Decision Node evaluating the change is structured as follows:

• Condition Logic: (1 OR 2) AND 3

  1. {!$Record.Id

} Is Null = True (New Record) 

  2. {!$Record.Company_Picklist__c} Is Changed = True (Field Updated) 

  3. {!$Record.Company_Picklist__c} Is Null = False (Ensures field contains data) 

Because of Condition #2 (Is Changed), when we perform a "no-change" Edit -> Save on the historical Record A, this decision path evaluates to FALSE on the client/payload trigger level. However, since the record is technically hitting the database transaction, the Before-Save Assignment element still executes downstream or forces an update, which is why the field gets populated in the database but completely bypasses the Duplicate Rule UI engine. 

Is it a known behavior that Salesforce completely skips the duplicate rule evaluation UI modal on an Edit -> Save transaction if the client-side payload detects no changes in the specific fields participating in the Matching Rule even if a Before-Save Flow alters database values during that same transaction?

Would you consider this standard behavior of the Salesforce optimization/indexing engine for duplicate management, or an edge-case bug with Before-Save updates on historical data?

Thanks in advance for your insights! 

,