As a workaround, you could try saving the current document position and restoring it.
One way to get to this would be Caret.DocumentPosition. To restore it, you have to convert document position to offset and set the caret offset. You can convert the document position to a offset using the document's (or view's) PositionToOffset method.
It's not optimal, but it'd be less annoying than the caret moving to the very END of the document. It would, however, change the selection if the user had text selected (since it won't preserve the selection, I think, though I haven't tried it so it's possible the selection would stay).
If the support guys are looking for other opinions, I too believe that this method should not modify the caret or selection. In fact, I think any methods that operate on the document should not modify the selection and/or caret unless one of the following is true:
1) the user would expect the selection to change,
2) the previous selection doesn't make sense anymore.
(1) I can't think of any cases that meet this criteria, except for the really obvious ones like calls that have the word Select or something in them...
(2) examples of this case are: deleting text that contains the current selection, replacing the current selection, inserting text into the document (maybe), etc...
Again, however, I take a very conservative stance with regard to the selection being modified. I'd say unless you're POSITIVE that (1) or (2) is satisfied, the selection should NOT be modified. If it's not absolutely clear cut - don't do it. The programmer can always write an extra line of code to do the selection change if they really want it in cases where you didn't expect them to.