One thing that's makes the product line a bit hard to reason about is that they have a Wifi and a non-Wifi version using two very different MCUs with very different power use characteristics. I.e. even if you have Wifi disabled on the Wifi version, it'll behave very differently from the non-Wifi board. People looking up numbers or experiences will have a harder time.
Add to this that afaict, the Arduino framework API currently doesn't provide fantastic abstractions for power/state management either. I had an Arduino-based esp32 project once and extracting best deep sleep performance definitely required reaching lower into ESP-IDF API instead (e.g. the difference between ext0 and ext1 wakeups and being able to shut off RTC memory in one but not the other).
That means with the current framework, you have to potentially write non-portable code between two different versions of the "same Uno R4" if you want to optimize for low power.
All of embedded is like this, really - scanning through and understanding a product line is basically a required skill - but meh, what a mess for beginners.
I could be wrong, but my reading of the post was that the Wi-Fi version has two MCUs - the main RA4M1, and the S3 WiFi module. So, if you turn off wi-fi, they should be effectively the same board.
Add to this that afaict, the Arduino framework API currently doesn't provide fantastic abstractions for power/state management either. I had an Arduino-based esp32 project once and extracting best deep sleep performance definitely required reaching lower into ESP-IDF API instead (e.g. the difference between ext0 and ext1 wakeups and being able to shut off RTC memory in one but not the other).
That means with the current framework, you have to potentially write non-portable code between two different versions of the "same Uno R4" if you want to optimize for low power.
All of embedded is like this, really - scanning through and understanding a product line is basically a required skill - but meh, what a mess for beginners.