Cc @JulienCochuyt.

I can reproduce mostly when typing the third letter after deletion, but also sometimes after the second and rarely after the first.
What bothers me the most here is that until the selection removal announce, braille is not updated either.
Still, all review commands report the correct content.

After adding a ton of log traces, I can confirm that IAccessible.event_valueChange is not called at all after the deletion and the first few following keystrokes.

Adding a small delay upon resetting the filter seems to solve the issue.
I don't feel this is much technically satisfying, though.
Upcoming PR.

It seems #11437 fixes this.

For reference, I am copying here other tests done from #11327.

STR:

• type "hello" in the filter field (without quotation marks)
• with the mouse select the word hello
• type "activatedX" (without quotation marks)
  Result: the selection removal is reported only when the letter "X" is typed. I have also tried the same STR typing NVDA+F2 before each letter of "activatedX" and the result is the same.

and

Moreover, if you type "qw" instead of "activatedX" the selection removal is announced as soon as you type the 2nd character (instead of the 10th for "activatedX"). It seems to me that this issue is directly linked to the filter functionality since the number of character that may be typed before the selection removal is reported seems to depend on the number of output results of the filter.