This is a conceptually sound choice, but it’s not clear if anyone has yet really work out the software details of doing so.
Typically it’s better to have your first experience of an end device be a more traditional flash-based ARM Cortex MCU (or else an ESP32) already known to be well supported with good instructions and a large community of people familiar with the details by something like LoRaMAC-Node or MCCI LMiC, and move to less common hardware only after there is experience.
and a RPI Zero as two End Point Devices
A conventional Raspberry Pi is a bit of an odd fit as a LoRaWAN end device, both in that the timing to do it correctly is possible but a bit tricky under a multitasking operating system, and that the firm requirement for mains power and the common desire to send far more data from a pi than LoRaWAN can plausibly support tend to point to it being a mismatch for a low power long range sensor-oriented network.
This is a good choice for a gateway to be installed in a location with very reliable mains power and easy access for maintenance should you end up needing to do something like re-image the SD card. It’s not really as suited to field deployment as gateway platforms with more dedicated embedded engineering and storage technologies more robust against unexpected loss of power. If using a pi, there’s no need for a recent one, a pi zero or even an old model B will work.
Specifically: is there any impact between the transition from V2 to V3 and all the hardware and software one can find around?
The main thing you need to watch out for is to avoid using “stale” software on either end, but especially the end device end. A lot of things that were never right but were sort of tolerable with V2 now cause real problems in V3 unless actually done correctly. So for example old forks of LMiC other than MCCI’s maintained one. And be particularly wary of anything that claims to make a pi into an end device being old and/or incomplete (transmit only, etc) in ways that will cause serious problems with V3.
For the gateway side you really want to use a packet forwarder recent enough to have the JIT queue, but since the sx1302 post-dates that software improvement, anything that supports it should be fine. “Basic Station” is considered more robust if you can get it to work, the sx1302 version of the “classic” packet forwarder could be your backup solution to get a gateway going.
Make sure that everything you buy is the product version for the frequency band that TTN uses in your location! Regrettably, online sellers sometimes stock frequency versions that are not just atypical, but actually illegal to use in the countries where they promote them for sale.