Why does my second Wi-Fi card disappear when both are running?

That behavior is almost certainly related to the order the hardware resources are claimed during the boot sequence, which is common when managing multiple network interfaces on a constrained bus. Even if the cards are identical, the operating system grabs the first available slot and initializes the corresponding driver before the secondary slot is fully ready for enumeration, especally when running over a shared PCIe switch. It is highly probable that the 2.4 GHz card is initiating its hardware handshake before the 5 GHz card has stabilized its power state or driver registers.

While power draw is a factor, especially with high-power Wi-Fi cards, the fact that the system runs fine after a manual reboot suggests the power rail is sufficient. The issue is more likely sequencing. Your theory about initialization order is correct, but before adding a simple delay, you need to ensure the low-level kernel modules are loaded and stable before the network stack attempts to claim the devices. A simple hard reboot of the host is just a brutal way to enforce this sequence.

If you want to handle this in software, you could look into custom boot scripts or maybe tweaking the kernel parameters related to PCI enumeration. Rather than just delaying the service start, you need to wait untill the kernel reports that all the required PCI devices are fully enumerated and ready. Check your system logs for errors related to the MiniPCIe bus during the initial boot phase, as that will point to the precise point where the second card fails to report itself. Waiting until the interface is active is better than waiting for the service to start.

Since you are using Docker containers, you might need to adjust the startup sequence of the services themselves to depend on a specific hardware readiness check. You want the kernel to fully register both cards before Pi-dock-wifi tries to bind any IPs or start hostapd on either one. This makes the system more robust to race conditions at startup.

I think focusing solely on the kernel sequencing is maybe overkill for this particlar build. It sounds like a lot of work just to fix a flaky boot state. My experiance suggests that when you cram two high-draw components onto a single board, the issue is often simply about the voltage staying clean. Even with the official power supply, those Wi-Fi cards pull power at diferent stages of initialization. If the Pi's power delivery dips even momentarily when the first card locks in, the second card might fail its self test at boot. Have you tried adding dedicated power filtering or testing them with a known stable power brick capable of handling the cumulative draw?

I tried setting up my Pi-based router once and it got super complicated with the software setup. It seemed like every single piece of code had to be perfect or the whole internet thing just stopped working. Since this project is running many different bits inside a container, could maybe the software in the container be fighting with the main operating system? It feels like there might be a bunch of different things trying to control the wifi at the same time.

I noticed when I built my own mesh network a while back, the issue wasn't the software. It was always the physical connection. I had a cheap piece of metal screwdriver set that let me check the MiniPCIe slots before I soldered anything. Just making sure those retaining clips were fully seated on both the 2.4 and 5 GHz modules made the whole difference for me. Even if the cards are identical, one might be catching the signal differently based on how tightly it's sitting in the slot. Sometimes a dusty slot can cause wierd initialization hiccups.

It might just be a subtle contact issue on the slot itself rather than the power draw or the OS sequence. Give the slots a gentle wiggle and check the alignment of the pins against the socket.