When is it unsafe to use TraditionalForm output in subsequent input?

Suppose I have MMA's global preferences set to always give me a TraditionalForm output. If I copy-and-paste one of these TraditionalForm outputs into a subsequent input and try to evaluate it (not my standard practice, but I do it occasionally), I get either of two warnings about TraditionalForm's ambiguity as an input (see screenshots below; the first warning comes after I paste, the second after I hit shift-enter; IIRC I always get either one or the other, never both). Questions:

1) Can I get some examples of TraditionalForm outputs that MMA subsequently misinterprets? I don't know of any myself [except see EDIT added below]. More interestingly, are there general classes of expressions that MMA will misinterpret and, if so, why?

2) If MMA does such a misinterpretation, will it always give an error? And if so, is it always clear that the error is due to the use of TraditionalForm? If the answers to both of these are "yes", then it's not a problem for me to do this since, in the rare cases when I get an error, I can easily correct it. My concern, however, is the possibility that MMA could misinterpret a TraditionalForm expression, yet not give an error.

3) What causes MMA to give me the first warning (which follows pasting) vs. the second (which follows shift-enter), and why do I never get both? And with the first warning, does selecting the "Paste Literal" option convert what I'm pasting to StandardForm (that seems to be what it's doing)? Regardless, if I'm offered, and select, the "Paste Literal" option, is the input always interpreted identically to a StandardForm input?

4) [Added after EDIT, below]. Suppose I don't copy-and-paste outputs into inputs, and don't use @TraditionalForm in my inputs. If I set MMA to output TraditionalForm globally in Preferences -> Evaluation, is the evaluation of previous outputs always the same as it would be if my output were globally set to StandardForm?

EDIT, DEC. 25, 2016:

I'd originally written that if one doesn't do the copy and paste, and simply feeds a prior result into a subsequent input, the potential ambiguity of TraditionalForm is not an issue, since MMA's internal representation of results is independent of how it prints them.

I'd thought this was the case for two reasons. First, as Wolfram explains in the MMA help documentation, under "tutorial/HowInputAndOutputWork":

"It is important to understand that in a typical Wolfram Language session In[n] and Out[n] record only the underlying expressions that are processed, not the textual representations that happen to be used for their input or output. If you explicitly request a particular kind of output, say by using TraditionalForm[expr], then what you get will be labeled with Out[n]//TraditionalForm. This indicates that what you are seeing is expr//TraditionalForm, even though the value of Out[n] itself is just expr."

And second, when I globally set Preferences->Evaluation to always output in TraditionalForm, I never noticed a difference in behavior. However, as @xzczd pointed out in the comments, my understanding was not correct. Thus:

If I set MMA to output TraditionalForm globally in Preferences->Evaluation, and execute the following code, I get the result shown on the LEFT of the screenshot below.

int = Integrate[x^2, x]
%/x
int/x
SameQ[int == x^3/3]


However, if I set MMA to output StandardForm globally, and manually direct MMA to output the evaluation of int in TraditionalForm (using the following code), I instead get the result shown on the RIGHT of the screenshot below.

int = TraditionalForm@Integrate[x^2, x]
%/x
int/x
SameQ[int == x^3/3]


Note that, in the latter code block, when int is used in the subsequent input, MMA doesn't interpret it correctly (see Out[4] on RHS of screenshot). [Or, if you prefer, it interprets it differently from a StandardForm input and, according to Wolfram, StandardForm is, well, the standard for inputs.] By contrast, MMA is able to correctly interpret the output of int when it's instead referenced using % (see Out[2], RHS). Consistent with this, on the RHS of the screenshot, while the head of %% (which references line in which int was assigned) is Times (see Out[3]), the head of int itself is TraditionalForm (see Out[5]. By contrast, with the former code, where TraditionalForm is instead output globally, the heads of both %% and int are Times, and the use of TraditionalForm does not affect how the output is interpreted.

Returning to the above-referenced help tutorial, note that it also says:

"The Wolfram Language also allows you to specify globally that you want output to be displayed in a particular form. And if you do this, then the form will no longer be indicated explicitly in the label for each line. But it is still the case that In[n] and Out[n] will record only underlying expressions, not the textual representations used for their input and output."

This seems misleading, because while Out[int = TraditionalForm@Integrate[x^2,x]] may be recording just the underlying expression, it is packaged with the TraditionalForm head, and this head changes the evaluation behavior.

• So, you're not interested in the possible misinterpretation happened when one copies and pastes a TraditionalForm output and uses it as part of a subsequent input? – xzczd Dec 23 '16 at 8:31
• @xzczd: Come to think of it, that would be of interest. I edited the question, explaining that the one case in which TraditionalForm may create an ambiguity is when you copy and paste the output into a subsequent input, and asked if there are examples of when this leads to an error. – theorist Dec 23 '16 at 18:49
• I'd like to point out the new added example is improper. The correct example should be TraditionalForm@Integrate[x^2, x](* line break here *)%/x, for more information, read this post: mathematica.stackexchange.com/q/132740/1871 – xzczd Dec 25 '16 at 11:43
• @xzczd: Thanks, I've corrected and improved my example. – theorist Dec 25 '16 at 23:01

Consider Subscript[K, a][b] (i.e., $K_a[b]$). If we use TraditionalForm, copy&paste, and execute, we get BesselK[a, b], at least in Mathematica 9.0 Linux edition. And you get no error message.
You can do the same with $J_a[b]$ (which becomes BesselJ[a, b]), $H_a[b]$ (which becomes HermiteH[a, b]), etc.