Ok, I recorded a video of the process of getting from A to B. There is a point in the video when I go to the preferences menu, but the screen capture didn't record the preferences window. This was when I enabled Auto Depth as suggested. As you can see in the video, it doesn't change anything. Towards the end of the video, I pressed 'Numpad ." to demonstrate the behavior that IS expected when the target object is moved.

Actually, I did try Auto Depth before submitting this bug, and it too has its own issues--like the slingshot effect--unless the 'Numpad ." button has been pressed. Some of the instructions above were written so that you had some sort of spatial awareness. They aren't necessary to recreate the problem, they just help visualize what's going on. What seems to be happening is that the camera orbits around and zooms into the original point in space, but when the 'track to' object is moved, the camera aims at the 'track to' object but continues to orbit and zoom into the old target point. I'll try to record the process right now.

That did it! Thank you. I read this is a new feature in Windows. Would it provide any benefit in Blender, or only cause problems?

I feel like I'm exhausting my options. Starting with the most recent, I kept rolling back drivers all the way back to September of last year with no luck. I tried the newest version of blender 2.91.2, 2.91.0, 2.92, etc. I changed my TDR settings to 60, I tried using one GPU at a time, I tried running the monitor at 1920x1080 instead of 4K, I deleted the Optix cache so it would make a new one. I've tried clean installs of drivers. My chipset drivers are up to date. Blender is the only thing that seems to have problems. I can, however, manage to render out the default cube in cycles with GPU. I just can't use rendered view in the viewport.

After closer inspection, it does seem that each half-sphere seems to be slightly higher than it's counterpart, by fractions of a mil. The problem is that I can't seem to get the two to achieve the same z-location numbers. Blender refuses to allow exact numbers. Is this a problem when working with small numbers?

OK, I see what happened with the original upload. I uploaded a file, but I must have deleted the number in brackets, not knowing that was the file. I did notice that somehow the second sphere was a micro amount higher on the z-axis, even though I used the array modifier to get it there. However, after moving vertices, it didn't seem to make any difference. I went ahead and deleted all other objects in the file to make the file size smaller. I can upload the full file if needed.

It may be worth noting that I can't seem to put in exact measurements in the original file. For example, I'll try to put in a number like 1" 250mil, but Blender changes it to something random like 1" 249.9997mil. I opened a new file to try and replicate the main problem, but so far, I can't. However, I can put in even numbers, like 1" 250mil, for example.

Did you modify the default startup file?

The above file had one command [Window>New Window] and was immediately saved.

There really isn't any additional information to produce. An empty file with dual-screen UI should reproduce the problem just fine. Simply saving the default file with a second window open will replicate the issue. I know this because I had to reinstall blender because I did this and could no longer successfully open blender.

I found out today that if I open blender on its own and open another window on the second screen before opening a dual-screen file, Blender does not crash.

I found out how to replicate this problem. I am now using Blender 2.8. I recently switched my right monitor to be the primary monitor and have managed to reproduce this error each time If I don't open Blender carefully. If you open a blender file without disabling custom UI, blender exits/crashes. If you open Blender on the primary monitor, move that window to a secondary monitor, and then open a second window, Blender exits/crashes. If you open blender on the primary monitor and open a second window on the primary monitor without first moving the first window to the secondary monitor, all is well - no exiting/crashing. When these errors occur, I usually get an OpenGL is required error, which doesn't make sense for these cards. I am now using two GTX 690's and a Tesla K10. It's not an ideal set up, driver wise, but for the most part, it works without flaws.