The following happens due by automatic simplification in the kernel (ie. you cannot delay it using delayed evaluation, once you get to this expression):
The following division does not suffer from that effect, and still using unevaluation quotes. But it is a relatively poor solution, since a pair of uneval-quotes will get stripped off upon each evaluation.
Solutions that require an ad hoc number of pairs of uneval-quotes tailored to suit the application are clumsy and poor. (Too few quotes and the effect vanishes, yet too many and ugly quotes are visible. It's a poor technique.)
There are a few other approaches that do not suffer from the ephemeral nature of uneval-quotes. One is to use an inert form:
Other choices include wrapping key parts with a call to ``(...) , which can be undone using expand or evalindets.
More work is involved if you want to replace forms in precomputed results. For example, to replace the following returned result one might sensibly wish to first check that the integer base of the radical in the numerator divides into the denominator.
But first you might want to consider whether this is for final presentation only, or whether you need computation/manipulation of the fixed-up/somehow-inertized expressions.