The example included in the IDF also uses the edge interrupts in a completely natural way, as if the erratum did not exist:
https://github.com/espressif/esp-idf/bl ... ple_main.c

I wonder if the ESP32 erratum 3.14 is still something to worry about when using newer IDF versions: https://www.espressif.com/sites/default/files/documentation/esp32_errata_en.pdf The .pdf file still mentions it, but when I use e.g. GPIO_INTR_NEGEDGE in my code, there is no warning whatsoever. I am ...

I cannot determine that. People are running the app on the ESP32-U4WDH (the old one and the new one).

Can I use a bootloader compiled for dual core on a single core chip? The app is compiled for single core. I somewhere read that we should not use a bootloader compiled for single core when the app is for dual core. But what about the other way round? The bootloader documentation does not say anythin...

https://github.com/espressif/esp-idf/issues/13448
The BLE hardware should be compatible. But Espressif is unwilling.

Maybe a tip: If you want to achieve more reach with your WolfSSL, why not put a NONOS fork online where MbedTLS has already been completely replaced, ready to use so to speak.

RTOS is no option since it demands way too much flash memory. We have hundreds of devices with 1 MByte of flash. RTOS does not fit there. So we are stuck with the NONOS.
Also, RTOS has a newer mbedtls. I think, anyone using RTOS has no need in changing this component.

So is it possible to replace mbedtls in the ESP8266_NONOS_SDK with this one? The existing mbedtls is quite outdated and does not support TLS 1.3 at all.

I am using Windows, VSCode and the ESP-IDF extention. I need to compile a project for several targets, for example ESP32, ESP32-C3 and ESP32-S3. I can do this manually by clicking the "ESP-IDF: Set Espressif Device Target" command, then "ESP-IDF: Build Project", then copying the binaries, and so on....

That is the mystery. It is the MOSI pin, the one called mosi_io_num in spi_bus_config_t.