An optional single pane of glass type configuration for multiple devices.
While some have a single openwrt devices, some of us have larger installations.
While we can make configuration files for identical devices, being able to control a heterogeneous mix of devices from a single interface would be awesome.
Thanks for giving us the opportunity to give feedback! - my wishlist:
There are no interesting things for me to choose from, so a small personal wish list ... 
I realize that the whole project is voluntary, just a few ideas that I would like to see in the future.
for example if release 26.01 reasonably drops 8/64 support keep 24.10 maintained until LTS kernel ends...
Improving and perhaps reorganizing documentation would be a very useful thing. While not as shiny as implementing new features, paying more attention to documentation will make OpenWrt easier to use (and develop for) for literally everyone. If proactively improving documentation is not feasible, at least consider improving responsiveness to community reports about documentation problems.
I miss a simple web interface feature:
This is to avoid applying wrong settings when you have many Openwrt devices on your web browser.
you mean like setting a colored interface based on selected environment ? (ie. living room / first floor /second floor)
=> if so I would agree that's a welcome addition
It would be nice if OpenWrt had a backup file as backward-compatible and robust as the pfSense config.xml.
I’d like an easy way to make captive portals, which are completely compatible with iOS and Android phones.
Whether they use DNS hijacking or another method.
I just want to be able to buy a router that runs OpenWRT, specify some static html files, which might contain CSS, images, Javascript and interact with some servers. And the captive portal would be set up. It could set a cookie or hit some endpoint with Javascript that would whitelist that session / MAC address.
Why I want this: I build social software for local area networks, such as events or classrooms or cruise ships or planes. Captive portals are great for everything from taking attendance (automatically, by joining the wifi) to creating an account (for some local network software), redeeming tickets, etc. You set it up once and then every time you connect to the wifi, it is automatic. No tedious taking of attendance, etc.
Something that would really help is pre-packaged device profiles that allow you to easily make the device work in a certain role. For example the default role when you install OpenWRT is that it acts like a home firewall, which includes NAT, DHCP, etc. However if someone wants to convert it into a dumb AP, they need to follow the wiki (which is very trial and error) to get that working.
This idea is that there could be an interface that allows one to "change role", and then pre-packaged scripts just do everything for you (install packages, enable/disable services, etc.). The project team would need to have a reasonable idea of what each role should include, and roles should be compatible with each other (e.g. the firewall role and the dumb AP role should have settings that are compatible with each other).
This might be extended to a concept of adding roles like building blocks (like adding a VPN server to the firewall), but that could get more complicated.
possibly LibreMesh Pirania (?)
see https://blog.freifunk.net/2024/09/10/gsoc-2024-new-release-for-project-libremesh-pirania-part-iii/
I had the same thought today when looking for some flag on dnsmasq just to realize, that the init.d script and the wiki do not match.
Then I thought - why do we not sync this like other projects do? Put the documentation with the code, so Pull Requests need to make sure both is changed accordingly.
And then you could also provide the documentation for different OpenWrt versions as well at the same time.
Have markdown files or something easily changeable and automated documentation generation like readthedocs or other projects. This would then allow to switch between versions for generated files.
It would also move the source of truth for code and documentation to the git repository instead of the current split between wiki - different accounts, different processes -, forum and git.
If someone is interested in that, send me a message, I'd be interested to talk about this and throw ideas around.
Because I have more that 2 devices with different roles, I will support @orev (and possibly others with similar requests).
It would be nice to have a way to build a customized firmware with a given set of packages (solved by firmware builder) AND easy way to provision these firmware with configs and secrets.
Something like a pseudo-partition in the end of firmware blob where I can put compressed cpio of /etc/config or even backup*.tar.gz.
Something like OpenWISP?
A initial quick setup in Luci like mentioned at https://lists.openwrt.org/pipermail/openwrt-devel/2020-June/029835.html (for non-tech-savvy users) would be nice.
I faced this issue with my old TP-Link Archer A7 v5. I wanted to give it to a relative flashed with OpenWrt and with CAKE SQM setup, but let them setup WAN PPPoE username / password, WiFi SSID and password. However due to lack of quick setup equivalent option in OpenWrt, I had to flash back the TP-Link firmware for them to be able to use the router.
Excellent ideas. I hope they get the attention of the devs.
I have a problem with the poll, so I did not vote. It intermixes internals with user-visible big features.
My preference among the ideas expressed in the comments is "stabilize existing features" but with a twist. Namely, some of the really great ideas, like multi-WAN support with automatic fail-over (via mwan3) or OpenVPN support look like something bolted on and not well-integrated. It seems like the authors of these features are fighting with the limitations of the OpenWrt core packages.
Also, I do agree that configuration for common use cases (e.g., a WDS repeater or a fail-over between a fiber connection and LTE) is excessively complicated.
To be clear I don't mean this to be related to custom firmware builds, I'm suggesting this as something within LuCi and maybe a command-line counterpart on top of an existing baseline firmware.
My idea is to make device configuration to certain roles easier for regular users.
I'd like OpenWRT to have an easy way to configure it to run as a wifi access point by default, not as a router.
I.e. you plug the device with it in existing network and it serves wifi to its clients bridging it.
Another idea: better security support.
One example of a problem is that I sent an email to contact@openwrt.org on October 21 regarding a vulnerable sstp-client configuration, but received no reply. Since then, I duplicated the report as a GitHub issue: https://github.com/openwrt/packages/issues/25212 (but failed to determine the maintainer correctly on the first try).