Shaping shouldn't be done using presentation form characters (in explicit mode). They have pretty limited capabilities, and even though aren't formally deprecated/discouraged, they should be avoided.
Shaping needs to be done by the emulator, on the characters is displays, even in explicit mode.
This approach can't count for the neighboring character if it's outside of the terminal's area designated for displaying that particular word (i.e. either completely outside of the terminal's area, or this area is used for something else, like a sidebar of the application or a vertical tmux split etc.). If required, a future extension could specify the invisible "neighbor" characters for each cell, a character (or at least its basic shaping-related properties) to imagine to be on the left for shaping purposes, and another one to imagine to be on the right.
There might also be a need for break points (e.g. where two semantically different fields touch each other on the UI), we should see if ZWNJ is suitable here (and where exactly it should be put in explicit LTR / explicit RTL modes), and whether ZWNJ is needed at all or the more generic "imaginary left/right neighbors" would make it unnecessary.
Anyway, these are for future extensions based on real life demand. In the first round, terminals should just perform shaping on the visual contents.