@brpc, in being answered, your request would loop back onto the content (and even subtext) of the other thread. I’ll explain, but first:
An interesting note. CTRL+F isn’t captured when you have insertion point inside a form element (input, textarea, etc). So, you do get browser native text search on the page by pressing CTRL+F twice.
However! An option to disable CTRL+F capture then requires that browser native CTRL+F functions properly, which comes back to the fact that Discourse can’t provide that in topics of more than ~10 posts because it doesn’t leave the entire topic thread in DOM at all times. Bottom line then goes all the way to a root ideology of Ember.js, which is that an Ember application is not a traditional (flat) web page in the sense that caused the browser native CTRL+F to be engineered. That then makes it fully OK to capture and replace the feature with something of like-kind, because the replacement both works as expected (it does full-text search of the topic content) and solves an issue with what it is replacing (you can’t have accomplished the expected thing without the new thing).
I think it’s easier for everyone, now that the captured search feature is improved since the other topic began, to leave that in place. It works well: far better than explaining to laymen users why browser CTRL+F isn’t working, every time they encounter that and ask.
The one thing I really lament about it is the fact that the UI response is moved and looks different… but that’s a UX issue that I don’t expect Discourse to solve today.