supports 5V input only.
That’s probably true. This board seems to only expect DC 5V input, not the 9/12/20V negotiated through the USB-C PD. But given that it uses TSMC 6nm and doesn’t support NVMe, the maximum power consumption of this board shouldn’t be too high.
5V2A or 3A can be found on many pd chargers and should not be that problematic, it’s just idea that violates PD protocol assumptions where You should operate on wattage and don’t check whatever particular charger has some mode or not. Now You can have 120W GaN charger that will not power up pi5 with sufficient power. Is this that hard today to use more voltages if needed? We will end up with pencil thick usb cable that need to carry 5V20A 
If implemented in any recent SBC, can change in a little monster 
.
My minimal requirements would be:
Without those satisfied, I am not interested.
I would love for Radxa 6 to have a solid PCIe implementation. Not sure if MediaTek is the answer since I haven’t seen an SBC with M.2/PCIe slot with them.
I’d easily be willing to pay more if it has an AV1 hardware encoder. 
Yes, 8Kp60 AV1 decoding.
If there will be a built in WiFi / BT chip, can you guys choose something other than AIC8800? The driver is really a pain (WiFi 6 not working with UniFi WiFi 6, Bluetooth driver unstable)
And if there’s space in the PCB, routing USB pins to the GPIO or having separate pins exposed for USB 3 makes it easier to make custom USB peripherals or extension boards.
Also to have a well tested Power Delivery 3.0 as I think lots of RPi 5 users and Radxa Rock 5 users are caught out by power supply issues.
Faster eMMC modules are also good to have.
And please hire more people to write full documentation! I know you guys work really hard but lots of things aren’t kept up with the latest changes so lots of your team’s time have been wasted to answer questions that could be solved by comprehensive documentation.
The RK3688 looks more interesting https://www.cnx-software.com/2024/10/04/rockchip-rk3688-armv9-3-aiot-processor-to-feature-a-16-tops-npu-ufs-4-0-storage/
Personally I would ditch the NPU and use that die space for as many core GPU as you can fit, as the frameworks vulkan and opencl offer far more interoperbillity than vendor NPU frameworks.
You also get two use cases where both ML and Gamers should be massively impressed than splitting that die space between a low core count GPU & NPU.
I guess the IP for a GPU is much more than vendor created NPU, the link says a 16tops NPU and if like the RK3588 and no where near rated, with a limited number of models that will run and a conversion framework that seems like Voodoo it all becomes very much less impressive.
