The new function will be much slower but it's still reasonably fast. This is an average case comparison, with the RX TSN randomly varying within the range:

In [17]: %timeit device.get_sequence()
626 ns ± 4.37 ns per loop (mean ± std. dev. of 7 runs, 1,000,000 loops each)

In [19]: %timeit device.old_get_sequence()
41 ns ± 2.47 ns per loop (mean ± std. dev. of 7 runs, 1,000,000 loops each)

Caching pending TSNs will only speed things up by 50ns.

I have looking little and Zigbee is using sequence counters in all 4 layers: 15.2, Zigbee Network, Zigbee Application and ZCL.
I think you is looking only on ZCL layer but i think it can being important also looking at the application layer for some scenario then some times you can using both for pinpointing the unique transaction.
One example for compare: IKEA Dirigera is Zigbee PRO then have all updated firmware so if one Rodret dimmer is sending one ON its only to the coordinator and the coordinator is doing one broadcast of the ON with different ZCL Seq (no group or device bindings, all in the coordinator).
In ZHA Rodret dimmer with group binding is sending 2 ON one to 0x000 (with EP) and one to the group (without EP) and both is with the same ZCL Seq but different Seq in Zigbee application layer (unicat all "jumps" is heaving all the same and all the braodcast is having one other).

That is making me thinking you must do the same for group Seq so they is not colliding with unicast Seq but is depends if you have locked down to the device / endpoint / cluster or is fully open then the sender is the same of the command (you knowing me and reading cod. . .).

I think you is on one very good approach that can solve some strange problems in some systems if getting colliding Seq and messing things up !!

2 interesting reflations:
IKEA Inspelning is one real network spammer then reporting the power attributes (i like it then its not as some Matter devices that reporting every 5 minutes) but if having more of them its little messy then sniffing and if sending commands to them its sooner or later using the same Seq for command sent and one attribute reporting = can getting problems in the system.

And IKEA Dirigera with all updated (Ziogbe 3) devices is one pure Zigbe PRO of lat version (likely 2023) then broadcasts is not being repeated then all routers is using passive broadcast ack (the broadcasting router is listening that all nigglers is repeating OK and not rebroadcast 3 times as old Zogbee is doing).

Thank you for the research!

That is making me thinking you must do the same for group Seq so they is not colliding with unicast Seq but is depends if you have locked down to the device / endpoint / cluster or is fully open then the sender is the same of the command (you knowing me and reading cod. . .).

Right now we only filter duplicate packets in a 10s window if they have the same source, destination (including address mode), endpoints, cluster, and profile. We ignore the APS sequence number. I think this is working and would not be affected by the issue you mentioned above where a device is reusing a TSN.

I haven't really looked too much at APS TSNs, to be honest, and I think we should look at how we do retrying: all retries of a request should use the same APS and ZCL sequence numbers, I believe.

By the layer as long doing ZCL all shall being OK only using TSN for that.
But we also do things in the app layer (Zigbee app layer that is under ZCL and abow Zigbee network layer) outside ZCL like manufacture cluster and "extended" commands. If we handling them the same was ZCL is doing it shall working OK. If not must implanting it for there function and the same for this functions (i think implanting touch link is being all outside but i can "living its own life").
It was some time ago i was diving in it but is one very deep rabbit hole but also interesting !!

Great work !!!!!

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.29%. Comparing base (a78dd9f) to head (6e3fcf3).

@@            Coverage Diff             @@
##              dev    #1636      +/-   ##
==========================================
- Coverage   99.31%   99.29%   -0.02%     
==========================================
  Files          63       63              
  Lines       12184    12198      +14     
==========================================
+ Hits        12100    12112      +12     
- Misses         84       86       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.