ToExpression and ToBoxes aren't inverses of each other?

It is well-documented!

According to the Documentation page for StandardForm,

• StandardForm generates output that gives a unique and unambiguous representation of Wolfram Language expressions, suitable for use as input. »

• StandardForm is the standard format type used for both input and output of Wolfram Language expressions in notebooks.

• StandardForm is based on boxes.

And then under the "Properties & Relations" section:

Use ToBoxes to get the box representation of an expression in StandardForm:

ToBoxes[x^2 + y^3, StandardForm]

RowBox[{SuperscriptBox["x", "2"], "+", SuperscriptBox["y", "3"]}]

Use ToExpression to convert back:

ToExpression[%]

x^2 + y^3

Based on the above I would say that it is well-documented that ToExpression and ToBoxes are inverses of each other when we work exclusively in the StandardForm (and the expression won't change during evaluation).

If one still isn't completely convinced, I would cite also Documentation pages for MakeExpression (which ToExpression uses under the hood) and MakeBoxes (which ToBoxes uses under the hood):

• MakeBoxes is the low-level function used in Wolfram System sessions to convert expressions into boxes.

• MakeExpression is used whenever boxes are supplied as input to the Wolfram Language.

Use MakeExpression to obtain the original expression in a held form:

MakeBoxes[1 + 1, StandardForm]

RowBox[{"1", "+", "1"}]

MakeExpression[%, StandardForm]

HoldComplete[1 + 1]

Summary

StandardForm is the default form used in Wolfram System notebooks which provides a unique and unambiguous representation of Wolfram Language expressions, suitable for use as input. On the low level it is based on boxes and one can convert any WL expression into boxes using MakeBoxes and then get the original expression backward in the held form using MakeExpression.

So the actual functions which (when working exclusively in the StandardForm) are exact inverses for each other are MakeBoxes and MakeExpression. Their only difference from ToBoxes and ToExpression is that they don't evaluate the expression.

Your particular issue

The issue you have encountered is indeed a minor bug.

You can fix it by making the following specific definition for MakeExpression:

MakeExpression[FractionBox["1", "1"], StandardForm] = HoldComplete[Divide[1, 1]];

Now

Nest[(ToExpression[ToBoxes[#]] &), Hold[1/1], 10]

Hold[1 1/1]

and

Nest[(ToExpression[ToBoxes[#]] &), Hold[Divide[1, 1]], 10]

Hold[1/1]

If you wish to fix also the conversion of Hold[1/1] input to Hold[1 1/1], you can add to the above a definition which will treat the 1/1 input in a special way:

MakeExpression[RowBox[{"1", "/", "1"}], StandardForm] = HoldComplete[Divide[1, 1]];

Now

Hold[1/1]

Hold[1/1]

Nest[(ToExpression[ToBoxes[#]] &), Hold[1/1], 10]

Hold[1/1]

A word of warning: I'm not absolutely sure that this solution is free from unexpected side-effects and won't break something in the system. If you encounter any issue, please let me know.

Comments posted by John Fultz in reply to Alexey Popkov, preserved for the record:

I wouldn't go so far as to make the claim that ToBoxes and ToExpression are inverse operations. I wouldn't even make that claim about MakeBoxes and MakeExpression. Expressions can have many representations in StandardForm, but necessarily, MakeBoxes must choose one canonical representation. Also, it's easy to create things which are not inverses, so even some sort of weaker statement must emphasize that this is convention, not a dictate. Finally, there are some boxes, most notably TemplateBox, which require FE secret sauce to properly convert into expressions. – John Fultz Sep 7 '16 at 13:48

There are simply no guarantees. Anybody can make any MakeBoxes and MakeExpression rules they want. The system enforces no contracts here. So, at best, your question only makes sense for what is typically true for built-in rules. Working under that assumption, there's still no guarantee that MakeExpression/MakeBoxes applied to a given set of boxes will return those boxes. There can't be. There's too many variations of boxes that produce a given expression (whitespace, comments, operators vs. fullform, prefix/infix/postfix, etc.). – John Fultz Sep 12 '16 at 7:15

So the only sensible variation of this question which can be asked is, are there conventions that guarantee, for a given expression, that MakeBoxes/MakeExpression will return the same expression. No, it is not guaranteed, although we do try. TemplateBox is a problem because only the FE authoritatively knows about them, but we do build in rules that do sensible things (and, in response to this question, we're updating those rules for the next release). But there are other cases, like size-limited output, or boxes with elided output (e.g., InterpolatingFunction) which still fail. – John Fultz Sep 12 '16 at 7:18