Not sure what they mean by "build my own router", it's easy enough to flash open firmware on a lot of tp-link models. https://download1.dd-wrt.com/dd-wrtv2/downloads/betas/2021/1...
To downstream, connect a good switch with port mirroring. (You might want to be able to capture traffic.)
Connect a wireless router as an access point or do double-NAT.
Let the AP be a dispensable component, not the main component of your network.
Yes. Agreed. Let routing and WiFi be 2 separate concerns handled by 2 different devices (or in the case of mesh-networking, classes of devices).
> You don't need much CPU power for a router.
Depends on how fast your link is. I could get decent routing on a mid-range MIPS-based device until I needed more than 300mbps. The CPU peaked and throttled traffic, because it was responsible for the NATing (ie actual routing, not just passing ethernet frames or TCP packets around untouched)
After that I needed a router with support for hardware NAT-offloading and it can do 1gbps actual routing just fine.
You probably don’t need to go full X86 + Debian, but depending on your needs, you may still find yourself bandwidth-limited because of CPU constraints.
while I cannot get how hardware can die from install different "driver" warnings like that put me off from using tp-links. Perhaps I'll buy a cheap tp-link and give it a try just as experiment to see how far I can get
There are many ways that could happen. For instance, the software could configure as an output a pin which, on that particular board, is hard-wired to a power rail; when the opposite value is set as the output (low when the pin is hard-wired to power, or high when the pin is hard-wired to ground) it would be a short-circuit. Or the software could configure a programmable voltage regulator to output a voltage which is higher than the maximum allowed voltage for one of the chips on that power rail. Or the software could configure more than one chip on a shared bus to output opposite values at the same time (again a short circuit, unless it's something like an open-collector bus). Or it could program invalid values on one-time-programmable antifuses, for instance setting the chip to use an external clock which doesn't exist. Or it could write an invalid program to the bootloader (for instance, it might be expecting memory to reside at a different address, so it always crashes) and there's no recovery method other than externally flashing the NAND (that one is technically a "soft" brick, but most people wouldn't be able to recover from it). And so on.