Are there any OpenWrt team members around?
Are you interested by this project or should I give up? 
You can submit your feedback there: 
aparcar has responded today positively with some requested caveats.
FWIW, I’ve found your initiative towards a better toh user experience a much better method and hope to see it included eventually.
The ball is in your court. 
Thank you for the nice words @RuralRoots 
I've just answered. 
I'm now hoping that OpenWrt team members will discuss among them if they want to integrate it or not.
I will then comply to their wishes.
we had a similar issue with the esphome web server version 3.
eventually, it was merged. this is normal.
Keep up the good work.
I will note that 24.10 is almost ready. @hauke posted this today:
OpenWrt 24.10.0 final is tagged and building.
I will probably announce the release on 5. February.
This new release has consumed 110% of the OpenWrt developer's brain cycles recently.
I would recommend that you wait until next week for the dust to settle. Then we can say, "In honor of 24.10, we also release a new ToH..."
Thanks for your good work and your patience.
It would be amazing!
Let me know.
Someone should run the service scripts for the current ToH, see:
https://lists.openwrt.org/pipermail/openwrt-devel/2025-February/043696.html
Good news: It seems that my new TOH should soon be added to the OpenWrt site. 
Thanks to all of you who have contributed to enhance it. 
If you're willing to help, I encourage you to submit your opinion about current suggestions "issues".
specially those:
thanks again, guys!
Thanks a ton! - I appreciate your efforts in improving this area!
Thanks a ton! - I appreciate your efforts in improving this area!
I'm doing my best, where I'm able to help, to give back to the absolutely amazing work of the OpenWrt team !
Happy to see that it seems to be helpful for the nice OpenWrt community members 
wifi Be checkmark is missing.
Is there an easy way to contribute to cleaning up the underlying data without using the Wiki, e.g. GitHub?
Also, the mini filter at least 16MB Flash & 64MB RAM might not be very useful. Should this be bumped up to 128 and more filter to 256? So mini 16/128 and more 64/256.
This was pointed out to OP in Oct already 
Not understood... please explain. 
Regarding Presets:
I've done my best to code most of the existing TOH features presets, using the existing ones as examples, and changed some fitting your suggestions in this topic.
The code is on my GH, to easily define filters presets (vs, the old obscure ones).
And this is now (i hope), reallly easy to define the filters presets to display.
One can also hard-link to a filter selection (= a custom preset) as an URL.
My contribution was/is to make the code for that.
Regarding what presets should be judicious to expose/link to from the wiki/upto date with releases, is not my task...
I will let it to the OpenWrt team (with the help of his nice community) to decide what presets to expose or not.
I'm not the boss
You have to understand that the database is NOT clean at all, actually.
I just (no other way exists TMK) rely on the TOH.json file (the "database") which is, (I guess) daily built by a quick&dirty script (at least is seems to be reliable) from the devices Wiki pages.
Those wiki pages entries, are NOT entered in a stuctured dabase, but rather as (not fully standardized) text lines, in a whole page text document.
Thus knowing if a device, is for example "Wifi AX", imply in my code side, to parse the "wlan24ghz" , "wlan50ghz", "wlan60ghz" fields, to REGEX if the "ax" keyword is present.
We are very far from a clean DB stucture where I could just ask for the "AX" keyword, or build a dynamic list from wifi types tables.
Also, a lot of fields that should be either YES or NO, can actually be filled, by '-' or ' ', or "?", or "yes/no".... not easy to accurately parse...
I'm doing my best, with how datas are currently received. 
So If you have an exact examples of existing TOH devices with ie "Wifi7", i would be able to add the corresponding filter feature!
Ok, so how are you detecting "ax" and "ac"? I grep through the toh.json and find various 802.11be references like this one:
"Yes",null,["-"],"b/g/n/ax","a/n/ac/ax","ax/be", ...
Seems like it should be pretty simple to mirror whatever is doing the matches for all the other 802.11 standards...