Looks like C++ doesn't come with built-in streams that can be navigated in reverse direction, as the default principle is to optimize for speed, and if data is read in forward direction and optimized by reading larger blocks + buffering them, std::istream::unget() may fail in proceeding before the current buffer block. Changing direction back and forth might result in throwing away an entire buffer block and having to read in another chunck, which defies attempts to optimize for speed, especially if those operations occur between buffer limits and there's no smartness built in to deal with dynamic buffer sizes. I have to either verify that std::istream::unget() can always go back to the beginning of the data source (which is unlikely, because it may be possible with some stream implementations and fail with others, for example data that arrived over the network) or have to come up with my own stream interface and implementation for a file source which likely may not be too optimized in terms of reading block chunks. I could also limit the stream type to file streams, but I would want to avoid that, if possible, so data can come from other places as well as long as they're not exclusively forward-directional. Introducing a new abstract stream class might be worth the effort for the "Reverse Streaming API for XML": when porting to Java, Java's streams might not have this limitation, and it can't be worse than JavaScript with no notion of streams whatsoever (as encountered with the JsStAX port). Another cheap solution would be to use the recently updated change_instructions_executor_1 that generates a separate file for every change instruction, and if I would also add some separate file that exports the instruction(s), I could navigate back and forth between those files as specified by the change_instructions_executor_1 result information file. But this would require such files to be copied locally (not to rely on any change_instructions_executor_1 output that might be subject to change or removal), and the need to have that many files around for a longer period of time isn't particulary better than keeping an exclusive lock on a change instruction file because the stream is currently reading it. In general, this option would make use of other existing tools of the system, which is a favorable property, but then we're in a GUI tool and not necessarily in a workflow anyway and the change_instructions_executor_1 could also still change in major ways (not that this would be a problem, but something to consider).