You cannot have two interfaces with the same subnet. It breaks routing.
What exactly are you trying to achieve, though. If this is a single device with 2 ports, those ports can simply be bridged together if desired. But I am a bit confused as to why you want to transfer data between two ports on the same device - it doesn’t seem to have a practical function.
@vgaetera is spot on. You have the two options listed in the above response.
Based on your diagram, it appears that you want the "other devices" to be on the ame subnet as the upstream connection. This means that you should follow the wifi extender link.
As far as your router is configured: I guess this should work. At least your router is not blocking anything.
Your firewall zone "lan" has a default behavior of "Forward" set to "access" as of the third drop down field in your screenshot.
I guess the devices in the 192.168.0.0/16 range on your WAN port simply don't have a route telling them traffic targeted at any 10.0.0.0/16 device had to be routed through 192.168.1.201. Why would they. There's really no reason for your ISP modem to even know anything about your 10.0.0.0/16 range, not be available at all and especially not being available via 192.168.1.201.
The situation is often called "there's no return route in place".
You can varify this by using tcpdump on your routers "phy0-sta0" port (as you called it in your second diagram). You will see packaes going out but not coming back.
Just as an example:
Your ISP router has 192.168.1.1
Your router has 192.168.1.201 on its WAN port
Your router has 10.0.0.2 on its LAN port
Your computer has 10.0.0.100 as it is connected to your routers LAN port
Some other device, e.g. a printer, has 192.168.1.150 as it is connected to your ISPs Wifi
Now go to 10.0.0.100 and "ping 192.168.1.150".
The traffic will go from 10.0.0.100 into 10.0.0.2, out of 192.168.1.201. It will reach 192.168.1.150.
Then 192.168.1.150 tries to respond . The answer goes from 192.168.1.150 into 192.168.1.1, leaving your ISP routers publc interfaces and off into the internet.
So your problem is with your network architecture in general.
My suggestion would be
to put the wifi uplink back into the WAN firwall zone,
to re-enable the "Masquerding" checkbox for the WAN firwal zone
and not to have any devices at all at the 192.168.0.0/16 side of your network. Everything should go to the LAN side of your network and get IP addresses in the 10.0.0.0/16 range.
Of course "routed client" or "wifi extender", as @vgaetera and @psherman suggested, will work, too. But that will render every other OpenWRT feature you might want to use in the future completely numb because it will reduce your OpenWRT device basically to a cable.
As a side note: Why are you using /16 networks? That's frankly insane.
Especially the 192.168.0.201/16 doesn't seem right. It looks lik your ISP tried to somehow make shure none of its customers uses a personal router of its own and doesn't VPN into anouther network (e.g. from your employer) as well, because there's a great chance they overlap. That's basically what happened in your first post: You created two completely different networks, used overlapping IP ranges and wondered why they would not communicate.
If I were you, I'd have a chat with my ISP to not use 192.168.0.0/16 but 100.64.0.0/10 for customer links. See: https://datatracker.ietf.org/doc/html/rfc6598
1 - I still have not solved the initial question (having 2 interfaces on OpenWrt with 2 IPs, communicating with each other)
2 - I resolved the wifi issue with relayd, putting a 192.168.2.10 IP on my router , keeping the /16 mask so my box is visible from the lan, and the relayd make it communicate between the 192.168.1,1 of the ISP to the 192.168.2.10 of my box, and further to any other device on the LAN side