Something that has irritated me for ages when developing using Toad is when I'm developing a package or such like (which has live syntax errors as it's mid development), and I change tab (perhaps to look at some other code, as a reference), when I move back to the package tab, it sometimes moves the caret to another position in the code. I think it is where the live syntax checker finds an error, so I lose where I was working on. It is BEYOND frustrating, as I have to find where I was, especially when packages are large (CTRL-Z is an option I suppose, but not ideal). I'm not sure in what cases it does this, as it isn't all the time, but I see this as a bug not a feature, as no other development IDE I know ever moves the caret. It simply shouldn't do this. I don't mind that happening if I double click the error info in messages, but not otherwise.
Actually, let me report on what I see because it's definitely not ideal, but may be different than what you're seeing.
Open a package for editing that spans multiple pages.
Introduce an error at the bottom and compile; error will be highlighted and the caret moves to the error location.
Scroll to the top, but do not click anywhere, i.e. the caret is still on the error, but out of view at the bottom of the package.
Activate another tab.
Return to your package.
The editor scrolls to show you the error and the caret remains at that location.
If I click somewhere at the top of the editor after scrolling in step 3 and then perform 4-6 then it's working as expected; the scroll position is correct as is the caret placement. Let me know if this is the problem you're experiencing.
I can't reproduce once I click somewhere else, but I've fixed what I see and I suspect it will resolve it for you as well. There is one spot in the code where we restore the Messages panel upon tab change and that code was jumping to an error location if there was one selected when you changed your tab from the package to the other tab. It should just be restoring selected nodes in the panel and not moving the caret position in this case. It should only jump to the caret when you actively click something in there. The next 16.1 beta (to be released Monday, May 9th) will have this fix in place. If you are a beta user please report back if it's OK or not.