CircuitPython version and board name

CircuitPython 9.2.8 on Pi Pico RP2040 with adafruit_irremote 5.0.5
A basic IR receiver module is connected to GND, 3v3, and a data pin

same behaviour:
10 beta 2 on Feather RP2040
10 beta 2 on WeAct STM32F411CEU6

Code/REPL

print("code.py")

import board,time
import pulseio,adafruit_irremote

# Maxlen is set high to mitigate a separate hard fault issue encountered, Adafruit_CircuitPython_IRRemote issue #76
pulsein = pulseio.PulseIn(board.D4, maxlen=600, idle_state=True)
decoder = adafruit_irremote.NonblockingGenericDecode(pulsein)
    
def main():
    while True:
        for message in decoder.read():
            if isinstance(message, adafruit_irremote.IRMessage):
                code = message.code
                print("Decoded:", code)
            elif isinstance(message, adafruit_irremote.NECRepeatIRMessage):
                print("NEC repeat!")
            elif isinstance(message, adafruit_irremote.UnparseableIRMessage):
                print("Failed to decode", message.reason)
            
            print("pulsein rem: ", len(pulsein))
        

if __name__ == "__main__":
    main()

Behavior

Following issues are while using the adafruit_irremote library but I believe it's caused by pulseio based on report here I believe is happening because of pulseio

Issue 1: Last NEC repeat code is "held back" until next button press and displaces that button press (the next button press after the late repeat will be correct)

Issue 2: Pressing a button multiple times without repeat seems to cause a duplicate to be inserted. For example if you press 5 5 8 8 9 9 on the remote with then CircuitPython outputs 5 5 5 8 8 9

Description

Here's why I think it's to do with pulseio:

• len(pulsein) is 0 after each NEC repeat, including the last one.
• It seems like a subsequent PR [to the irremote lib] means _unparsed_pulses to be fully cleared out each time so there won't be any unparsed pulses there
• There is clearly some form of extra data/state being held until more pulses arrive but the above 2 showing as empty makes me believe it must be coming from a user inaccessible part of PulseIo

Additional information

• I used a logic analyzer to verify the pulses being sent to the board match what's being pressed on the remote
• Willing to do more testing but not sure what else would test PulseIn in the same way. Maybe a really slow UART stream?