I wrote my message in a hurry. Let me clarify it.
I'm only talking about built-in tooling. I don't mind if a user have the
feature you're proposing, of course, as it is not wrong per se.
However, I believe that's not the best solution for the problem we're
trying to solve. I think there's an opportunity to provide something
smarter, and less intrusive, to handle emphasis, which doesn't involve
messing with `post-command-hook'.
I agree with you that my solution is somewhat intrusive. Ideally, I would have preferred that my solution could leverage advice functions or some Org hook, so that I wouldn't have to modify org.el, but it doesn't seem like there is a straightforward way to do that. The modification of `post-command-hook', similar to one used for `prettify-symbols-mode', only occurs if `org-auto-emphasis-mode' is active
Like in a word processor, you don't need to see the markers to operate
on them. I don't think the usual "toggle" model is appropriate, however.
I suggest to use two commands: one for deleting the markers around point
or within active region, and one for inserting markers or extending
existing ones.
So in your system, in order to interact with emphasis markers, the user would have to learn two different commands? That doesn't seem to be in line with the dwim philosophy used in modern emacs packages.
In my opinion, one of the strengths of Org is that the interface is multimodal. One can (in principle) edit documents in much the same way as word processors and rich text editors. However since everything underneath is implemented with just text, one can also directly access and manipulate this text. The ability to switch between these two modalities is extremely powerful and is what sets Org apart from other document editing systems.
Allow me to polish up my draft a bit, so we can compare the benefits of
each system.
I look forward to seeing your proposed system more concretely.
Shankar Rao