UNO With Wifi - addressing pins from ESP sketch

I am new to Arduino (although a very experienced programmer in a number of languages).
I am working on a project to gather data from the serial port of a Dylos dust monitor and forward it to a WIndows PC via WiFi.
It is close to working but I am trying to run diagnostic processes to fine tune the behaviour.
I have successfully set up connections between the UNO & ESP parts of the board using Serial (fairly native), a further serial connection through an RS232c converter to talk to the Dylos and a diagnostic serial connection through another RS232c converter connected to Putty on my PC (from the UNO part only).
After numerous searches through your site and the internet in general I still have a very limited understanding of what PINs may be able to be addressed from within the ESP sketch. Two specific issues here: 1. It would be good to connect the Serial-to-Putty to pass diagnostic messages from the ESP sketch; and - 2. On a few ocassions I have made small changes in the ESP sketch without making any changes to the UNO sketch and the behaviour of the diagnostic info being sent from UNO sketch to Putty is weird and stops working as it did before the change.
I can provide sketch code if anyone thinks there may be an issue there but - really - I just want to know what pins do what when being talked to be the ESP sketch.

Small additional detail:
Native UNO to ESP Serial assumed to use pins 0 & 1.
Dylos serial converter connected to pins 2 & 3.
Diagnostic serial connected to pins 4 & 5.

is it the Robotdyn Uno+WiFi board?

It is an XC4411 purchased from Jaycar here in Australia.
I think it is similar to the one you have mentioned.
It is certainly not a ... Rev2. I have ordered one of these at much greater expense than the Jaycar one in the hope that it may solve some of my problems.
I was about to post this link when I saw your reply. is a picture of the pinout for the Rev2. I assume my board is similar. Even so (at the risk of sounding narky) it is not clear what the markings in the orange areas mean and this is so typical of this space to which I am a newcomer. I guess the markings in the areas that are brown with diagonal orange stripes are the default UNO reference to each of these pins. Are the orange ones the "ESP" names?.
Also, I have found some references on the web to pins being used to address the on-board memory. Again it is not clear whether the pin numbers referred to are the pins on the memory chip or the pins on the board.

Uno WiFi Rev 2 is very different. it has ATmega4809 and esp32.

does your board have the DIP switches to switch USB, ATmega, esp8266 connections? does it have the esp8266 header documented on the Robotdyn page pinout.pdf?

My board appears to be identical to the robotdyn example.
Physical features match perfectly. Only difference is the screen-printed logo.

The orange ones are processor pins (of the main processor).

so is it now clear? the esp8266 pins are only on the esp8266 header. the rest of pin headers are as normal Uno.

Thank you Juraj. Yes it has become clear.
I got a diagnostic serial connection running on Pins 2 & 4 of the ESP header and this helped me solve all my problems.
Main issue was that the ESP sketch started out by beginning the serial connection to UNO and then WiFi and then the TCP stream. All of this took about seven seconds. In the mean time, the UNO sketch has also started the serial connection to ESP and then the external connection to the dust monitor. UNO then began a process of getting time from the PC to adjust RTC. This certainly began before ESP had finished its own start-up.
Fix 1. ESP now sends a simple serial message to UNO when it has completed start-up.
Fix 2. UNO doesn't do anything until it gets this message. The dust monitor sends readings over serial once per minute so the first thing the UNO sketch does is to wait for the first such reading. This can take anywhere from a few seconds to nearly a minute but by getting the first one and discarding it, the sketch then has a minute to complete the start-up process to synchronise the RTC and them wait for the first reading.
All has now been running without fault for a few days.