Revoked Non-Consumable Purchases & currentEntitlements

We use Transaction.currentEntitlements in StokeKit 2 to unlock functionality based on a Non-Consumable IAP but we have a case involving a refund that seems wrong and I am trying to understand the interation between transactionId, originalTransactionId & revocationReason.

The Context:

• We have a universal App on macOS and iOS that offers a shared Non-Consumable IAP. For this example I have named it "app.lifetime"
• On macOS we use StoreKit 2 and I am calling the Transaction.currentEntitlements and Transaction.all functions.
• On iOS we are still using StoreKit 1.

This example customer:

1. Originally purchased "app.lifetime" on 2024-10-27
2. Was refunded by Apple for "app.lifetime" on 2024-10-29
3. Re-purchased "app.lifetime on 2025-02-24 (I have seen an email receipt of this transaction but it never shows up in Transaction data)

(all the above happened on the mac via StoreKit 2)

The Transactions (all lightly redacted for privacy):

on macOS the following is returned from Transaction.currentEntitlements...

{
  "appTransactionId" : "...8123",
  "bundleId" : "app",
  "currency" : "USD",
  "deviceVerification" : "...",
  "deviceVerificationNonce" : "...",
  "environment" : "Production",
  "inAppOwnershipType" : "PURCHASED",
  "originalPurchaseDate" : 1729997808000,
  "originalTransactionId" : "...9955",
  "price" : 1,
  "productId" : "app.lifetime",
  "purchaseDate" : 1729997808000,
  "quantity" : 1,
  "signedDate" : 1740416289102,
  "storefront" : "USA",
  "storefrontId" : "143441",
  "transactionId" : "...7511",
  "transactionReason" : "PURCHASE",
  "type" : "Non-Consumable"
}

Note in the above example the originalTransactionId & transactionId are different. Transaction.all however returns both transactions:

[
  {
    "appTransactionId" : "...8123",
    "bundleId" : "app",
    "currency" : "USD",
    "deviceVerification" : "...",
    "deviceVerificationNonce" : "...",
    "environment" : "Production",
    "inAppOwnershipType" : "PURCHASED",
    "originalPurchaseDate" : 1729997808000,
    "originalTransactionId" : "...9955",
    "price" : 1,
    "productId" : "app.lifetime",
    "purchaseDate" : 1729997808000,
    "quantity" : 1,
    "revocationDate" : 1730224102000,
    "revocationReason" : 0,
    "signedDate" : 1740415969925,
    "storefront" : "USA",
    "storefrontId" : "143441",
    "transactionId" : "...9955",
    "transactionReason" : "PURCHASE",
    "type" : "Non-Consumable"
  }, 
  {
    "appTransactionId" : "...8123",
    "bundleId" : "app",
    "currency" : "USD",
    "deviceVerification" : "...",
    "deviceVerificationNonce" : "...",
    "environment" : "Production",
    "inAppOwnershipType" : "PURCHASED",
    "originalPurchaseDate" : 1729997808000,
    "originalTransactionId" : "...9955",
    "price" : 1,
    "productId" : "app.lifetime",
    "purchaseDate" : 1729997808000,
    "quantity" : 1,
    "signedDate" : 1740416289102,
    "storefront" : "USA",
    "storefrontId" : "143441",
    "transactionId" : "...7511",
    "transactionReason" : "PURCHASE",
    "type" : "Non-Consumable"
  }
]

Note here that the original transaction ("...9955") includes a revocationDate and revocationReason that match the expected refund but the secondary transaction that seems to match on all other details is missing the revocation info.

Looking at the iOS SK1 receipt data to compare, after a receipt refresh I see only a single transaction "...9955" which includes the cancellation info and transaction "...7511" is not present at all. The impact of this is that on iOS we are considering the purchase void but on macOS we are following currentEntitlements and consdering it still valid.

Calling the inApps/v1/history/... server API with the "...7511" transactionId that is shown in the currentEntitlements response returns the "...9955" transaction with the correct revocation status but "...7511" is no returned at all.

To Summarise:

1. currentEntitlements on macOS shows transaction "...7511" as active and with an originalTransactionId of "...9955"
2. all on macOS includes both "...7511" as active and "...9955" as revoked
3. iOS reciept data shows only "...9955" as revoked
4. Server API shows only "...9955" as revoked event when explicitly called with "...7511"
5. Neither of them show a more recent purchase the same customer made for the same IAP product.

My questions are:

1. Is this a StoreKit bug or am I mis-understanding something? If it's a bug how can I work around it to ensure revoked purchases aren't still appearing in currentEntitlements?
2. Under what conditions can StoreKit generate multiple transactionIds for the same underlying originalTransactionId? I had assumed (and the docs suggest) this only happens for subscriptions but here it is happening for a Non-Consumable IAP.
3. Why would transactionId "...7511" only be present on macOS/SK2 and not visible at all on iOS/SK1 or API?
4. I don't understand why the latest IAP from 2025-02-24 that the customer assures me they made (and has shown me the receipt for is not showing up in the Transactions history at all. Any ideas?