Moving VO cursor to keyboard cursor becoming a root problem

Technically, the blinking underscore, vertical line, or block that is meant to indicate the input position in text, is called a caret. The caret is a feature of text views that allow selection regardless of whether they are writable, and for this reason it is actually referred to as a selection range in AppKit, UIKit, and WatchKit.

In graphical user interfaces, input events can either be localized, as is the case with mouse events, or global, as is the case with keyboard events. Whereas localized events are simply sent to the first element in an event handler chain whose bounding box contains the event location, the lack of location information in global events means that an element must be selected to handle those events first. In AppKit, UIKit, and WatchKit terminology, the event handler chain is called the responder chain, and the element that is selected to receive global events is called the first responder. Typically only views representing controls declare themselves able to become first responders, and graphically speaking, they usually tend to communicate their focused status by displaying a visible thin outline representing an axis aligned bounding box, with elements that support caret navigation optionally also displaying a caret or text selection highlight.

As far as VoiceOver is concerned, keyboard cursor refers to the accessible element with first responder status, which is a different concept from the text selection range or text caret, so telling VoiceOver to jump to the element with the keyboard cursor will just trigger the default and intended behavior of announcing the element that gets focused by VoiceOver. I don't think that VoiceOver has the ability to read everything starting from the caret though, at least I could not find any relevant commands in VO+H, and since VoiceOver avoids reading large portions of selected text, I don't think there's a way to accomplish what you wish short of binding an automation script to a shortcut control, which while possible is not trivial to get right due to the general lack of proper AppleEvents support in third-party applications.

Finally, the NSTextView class used to provide rich text editing functionality by many applications has been kinda broken in terms of accessibility for at least 11 years, which is how long I've been blind, so even if there was a way to tell VoiceOver to read all the text starting at the caret, it would likely be impaired by the accessibility problems in those views only making the line where the caret is positioned available to the accessibility infrastructure.