I really, really want to like the RP2350. The PIO machines punch so far above their weight that they could turn the chip into a killer solution in a lot of circumstances.

This single erratum breaks my intuition enough that I'm "scared" to pull the chip into a design. I understand that they don't automatically break most use cases and that there are software workarounds. But they violate a core "Hi-Z is Hi-Z" understanding that I design around, and I'd really hate to respin a board over something so dumb. On an STM32 this would have been a silicon stepping and that's what bugs me about it.

My take is that devastating errata is just normal. Most of it is fixed silently and the end users never hear about it, but sometimes you're the customer that gets to find them. Right before I joined an embedded device team at Google, they brought up a new chip. Turns out... branch prediction was broken. It would mispredict a branch and execute the misprediction anyway. I imagine that was no fun to debug. But a workaround was fine and I'm sure subsequent customers never heard about it, and the devices worked fine for many years.

One time I lived in an apartment that suffered from a variety of pests coming in. I expanding-foamed everything that looked like an entry point, the problem went away, and I stopped caring. However, I could still hear mice crawling around inside the walls late at night and decided just not to be bothered. This experience prepares one for embedded systems / microcontroller work ;)

I mean, it's normal for like half of the peripheral functionality on STM micros to outright not work. But usually that’s something relatively niche like the CAN transceiver or the DMA controller targeting a particular MMIO range or some specific mode of the external memory interface. Having an erratum affecting literally all GPIO pins is unusually scary.