The Nvidia article (https://wiki.archlinux.org/title/NVIDIA) provides lots of information.
The Troubleshooting link in it might be useful.
I’m not using multiple monitors with Nvidia but only one bigger screen, so unfortunately I don’t know all the tricks. 
Update - I’ve just about solved the issue
After much “throwing settings against the wall to see what sticks”, I have found that temporarily disabling the 4K monitor on the RTX 2070, and then re-enabling it (as to force it from being X Screen 0 to X Screen 1) has more or less solved the problem.
Now I just need to figure out how to un-zoom the GUI, since it’s still using the 4K’s “100%” zoom as a base.
I will likely follow-up if/when I fix the zoom problem.
Update - The end may be in sight
While I haven’t fixed the Zoom Problem yet, I may have found the solution: manually setting the screen positioning, scale, etc with an xrandr command. This is going to take me significantly more maths than I use on a monthly basis, so my next update may not be for a while.
This wouldn’t solve the issue of the primary screen getting reset (i.e. notification area and Fancy Tasks bar position), or the wallpaper only showing up on one screen, but those are lesser issues at the moment.
Have you also created an xorg file specific for the screens?
Ultimately what I have done as far as xorg.conf is concerned, is that I made a backup that I could nano into from tty1, and manually overwrite onto xorg.conf if I broke something. Then, I let nvidia-settings replace xorg.conf with each attempt I made until I stumbled upon forcing the RTX 2070 onto X Screen 1. I can send the updated xorg.conf after lunch if desired.
No i don’t need it i was just asking because i don’t use the nvidia settings ever. I let nvidia-inst install the drivers and it creates that /etc/X11/xorg.conf.d/20-nvidia.conf Then the special xorg file is created for the screens.
https://wiki.archlinux.org/title/Multihead#Configuration_using_xorg.conf
Update - The End is Delayed
Today my EVGA SuperNOVA 650 G3 melted on Pin 2 of VGA 2 (Which just so happened to be the connection used by my RTX 2070)…
Thankfully, the GPU seems to remain alive and well.
Update - The End resumes Soon™
After half a month of scheduling conflicts, I have proceeded through the RMA process for my PSU, and the replacement should arrive this Saturday.
Prior to this setback, I noticed that newly installed apps did not have the zooming error that my existing apps did. Because of this, my incredibly jank solution to this is currently to swap out various components to some alternatives/different builds. Example - I used Brave Nightly as my browser, but I am now using it solely for PWAs, and swapping to Brave Dev for my general browsing activities. Might swap to Krusader over Dolphin, but I’m still undecided.
Update - The End is teasing me.
Bullet points since last update:
-Installed new PSU
-DE wouldn’t initialize
-reinstalled EOS
-got screens back to the same point as last update
-googled “kde plasma how to set scale below 100%”
-reddit thread suggested adjusting font size
-shrunk font, everything was way to small
-defaulted font AND THE SCALE RETURNED TO NORMAL
-restored pre-case swap backup of EOS
-forcing 2070 to X Screen 1 isn’t working anymore
-I have been spending all day backing up, tinkering with, and restoring xorg.confs, and occasionally re-restoring the backup install when I royally screw something up (like trusting .bak instead of using literally anything else to make a backup file)
-I hate M.2s
Why?
Because I’ve to constantly take the backup one out and put it back in because GRUB doesn’t like it when I try to launch into an installation with a seemingly identical one on another drive. Additionally, my set-up does not lend itself well to M.2 troubleshooting.
Do you have a different OS on the other identical m.2 drive.
No. I use Gparted Live environment to restore my pre-case swap backup of EOS. If I leave it installed afterwards, it’s a crapshoot whether or not I boot into the non-backup even if I select the non-backup directly from the UEFI.
Update - The End. Is. Here!
kind of.
The end of me trying EndeavourOS for this. I probably could do a reinstall and just hope that everything works - but I think I might just need a break from EndeavourOS. I’m going to give BlendOS a whirl, and see how that goes. I’m still gonna install EOS on laptops and spare computers as a default, and I may even come back to it in the future. But every single time I felt I was close to an issue being solved, I’d make the slightest change, and nothing would work.
-Changing the font stopped completely fixing the scaling
-Installing a different branch/alternative to various badly scaled apps stopped fixing scaling
-DISPLAY=0.1 [program] & stopped launching programs on the 4K
-Steam no longer launches
That said, I don’t feel that all of my time has been wasted, I’ve learned a lot in this year of trying to get it to work on my main rig.
But until then, so long and thanks for all the fish.
BlendOS? That’s immutable… 
Green like Nvidia! 
I believe the syntax should be something like
DISPLAY=:0.1
Please note the colon after assign (=) mark.
I can be wrong about the syntax.
Though not sure if this helps anything, but worth a try.
I might insert EOS retries between other distro attempts, but only if the Ventoy supported has been fixed. At some point, the live environment stopped booting when selected from Ventoy and it’s been a pain in the ass to run the below code every single time I need to reinstall or chmod for recovery. If this has been fixed in R3, then sure, I’ll throw it in rotation.
mkdir /run/ventoy/
mount /dev/disk/by-label/Ventoy /run/ventoy/
mkdir /run/archiso/
mkdir /run/archiso/bootmnt
mount /run/ventoy/EndeavourOS-Cassini_Nova_0*_2023.iso /run/archiso/bootmnt/
exit
exit
(* because I can usually tab complete that)I have had no issues installing EOS with Ventoy. Is your Ventoy stick the most recent version?
No, it’s running using Cassini Nova (with no RD#). I’ll throw the most recent on my stick and report back.
Well, assuming you meant “is the EOS iso the most recent version”, it still throws me into the same rootfs recovery environment.
Edit- worse still, the above code doesn’t fix the issue.