Serial USART0, Serial1 is USART1, RX0/TX0 is for USART0/serial, RX1/TX1 is for USART1/Serial1.
Each of those have the default pinset, and an alternate pinset. This is exposed by Serial.swap() - Serial.swap(1) switches to the alternate pins, Serial.swap(0) switches back to default, and it has to be called before Serial.begin() for us to guarantee that it will work
Also worth noting that the megaTinyCore docs are markedly worse than the DxCore docs now. megaTinyCore has too much stuff in the main file, making it a wall of text that's painful to wade through. As time permits I'm planning to port the docs back - the modern tinies and the Dx-series are very similar.
The pin mapping on the 2-series is... strange in that the alternate pins for Serial and the default pins for Serial1 are the same. I've not yet tried Serial.swap(1) (moving it to the alt pins) and then Serial.begin(115200) and Serial1.begin(115200) - they would then both be trying to use the same pins, and it's not clear whether one of them would "win" or if they'd both be controlling the pins, and in that case what it would mean. And - surely not coincidentally - two of those three pinsets happen to be on the same pins as an the SPI default and alternate mappings - clearly there's some silicon reuse going on under the hood!
The diode in that schematic is backwards - (and it needs to be a schottky diode with the band towards the TX pin of the serial adapter - Serial is idle-HIGH). I tried using one of those mux ICs. My first attempt failed impressively hard and I never got around to figuring out why (my plan btw was to use a 6-pin FTDI header to connect the adapter/programmer board to the target, and have the "CTS" pin on the target actually connected to UPDI. On the latest versions of my breakouts, thats one of the three things that the CTS line can be tied to with solder bridge jumpers. I laid out what I hope will function as an HV UPDI programmer via serialUPDI or a serial adapter. But I'm not getting over-confident, after my previous attempt failed as it did (I managed to totally bung the assembly of >50% of them, one of the worst rates I've had, and the ones that survived that didnt work; I'm not sure if I made a major blunder in the design, or just repeatedly fumbled the assembly.
That said, I've become more or less convinced that you don't actually want the UPDI programmer and the serial monitor to be on the same serial port -you want to be able to have monitor port connected to a serial console, while you upload with another port. Especially on these damned reset-less tinys!