@mmcdara Two minor comments:

1) Carl's reformulation can be had by,

   exp(simplify(ln(f))) assuming t>0;

2) If you don't want to have fiddle with resetting UseHardwareFloats (after setting it to false) then you could make your particular expression non-evalhf'able in the following kludgy but quick&temporary way,

   plot(eval(f,exp=%exp), t=0.9..1.12);

Since the default for UseHardwareFloats is deduced then you could also avoid evalhf by setting Digits>15 . So if you don't mind higher working precision then another way to get that temporary effect, without having to set/re-set Digits, is,

   evalf[16](plot(f, t=0.9..1.12));

@MaxOJ You're welcome.

ps. I'd supposed that you probably already knew why it gets a parabola, and wanted to use that command on purpose.

Download pl_ex.mw

@sand15 I'd already figured out that it broke because of the adaptive=geometric algorithm new in Maple 2022. The cause is already quite straightforward to pinpoint.

And, as I'd alluded, it worked fine in prior to Maple 2022, ie. Maple 2021.2 and earlier.

I do put such information in the bug report, when I know it.

[edit] In Maple 2023.0, the default for the adaptive option is (cryptically),
    adaptive=default
Using the OP's T(x,4) the plot command dispatches it as if one had supplied adaptive=geometric, and the portion is missing. But using expand(simplify(T(x,4))) the plot command ends up dispatching for this example it as if adaptive=true had been supplied, and the curve portion is not missing. It's possible that it tries the fallback due to computing (only? too many?) undefined values in the "geometric" method's tools.

@delvin Duplicate Question threads on this will be flagged as such, and may be deleted.

@madhav123 Please do not spawn wholly separate new Question threads for this same topic.

Instead, you could add your close followup queries or additional details here.

Attached is an edit to your most recent followup:
   Shear_coefficient_-_gyroscopic_couple_ac.mw

@C_R 

restart;
with(geometry):
_EnvHorizontalName := 'x':
_EnvVerticalName := 'y':

point(P1, -1, -1):
point(P2, 1, 1):

ellipse(E, ['foci' = [P1,P2], 'MinorAxis' = 2*sqrt(14)]):

Equation(E);

                   2                 2           
              240 x  - 32 x y + 240 y  - 3584 = 0

@mmcdara I mentioned in my Answer that piecewise's behaviour here has a similar explanation to that of `if` -- since it too has special evaluation rules and thus the argument sequence is not flattened.

(I've now italicized that sentence in my Answer, which is intended in the context of what I wrote about `if`'s evaluation rules and the non-flattening of the argument sequence.)

@delvin Please add any followup queries/details for this problem here (or one of your other threads on the topic), instead of spawning another wholly separate new Question thread for it.

This looks like degradation, to me, in both 2D Input and 2D Output.

In Maple 2021.2, and back at least as far as Maple 16.02, the unary negative sign in front of the "3" is slightly shorter, and closer to the "3".

To my eye, the difference is more pronounced in the actual Maple GUI than it is in these reduced screenshots.

And, in Maple 2022.2 and Maple 2023.0, that is no longer the case,

@Carl Love There is Typesetting:-RuleAssistant which is a Maplet utility, and there is Typesetting:-Settings for some programmatic stuff.

But I don't see either as handling the unwanted left-ticks for this case special of double-underscore name, when pretty-printed as 2D Output with (default) typesetting=extended. It seems a problem not present in M2021.2, new in M2022, and corrected in M2023.0.

@mmcdara Apparently the problem is that in Maple 2015.2 (at least) the GUI does not like embedding the content if the PLOT plotting structures have a ROOT plotting substructure as their last argument. (It's all unevaluated function calls used as data structures).

The ROOT plotting substructure contains the encoded background detail.

A workaround is to move something else to the end of the PLOT structure. Below, I use a utility to move the VIEW substructure last. This makes your examples work in Maple 2015.2.

DocumentTools_and_Background_ac_2015.2.mw

(I was surprised that the order matterered to the GUI. The problem can be induced in Maple 2015 even for a single curve in a single plot, where merely wrapping that in a call to plots:-display re-orders the substructures into the problematic form. And it's not just a problem with embedding into the open, current worksheet; using ContentToString to write it out to a .mw file can run into the same problem.)

@ijuptilk I have set the "Product" marker on this Question to now be "Maple 18".

If you are using such an old version (9 major versions, and 9 years, out of date) then it would be more helpful and polite if you would mark your questions with the right Product when you create them.

@Rouben Rostamian  Yeah, sometimes it gets awkward. Other alternatives here include,

with(Typesetting):
expr := 1 + x^2:
Typeset(AD(addressof(sqrt(expr))));
eval('Typeset'(sqrt(expr)));

It can be partly a matter of taste and habit.

@Rouben Rostamian  There is some overlap with the InertForm package. For example,

p1 := ee -> Typesetting:-Typeset( ee ):

p2 := ee -> InertForm:-Display( ee, 'inert' = false ):

expr := piecewise(x>0,-sqrt(x),x):

evalb( p1(expr) = p2(expr) );
                              true

The Typesetting functionality is broader, and has been available for considerably longer than InertForm (new in Maple 18, and simply itself invoking Typeset in the example above).

Here's another case that crops up. Suppose f has been assigned a value and I want an effect like, say, typeset("This is ",'sqrt(f)') in a plotting caption/textplot/title/legend/label, using the literal name f. If I assign that plot to P then all of its contents would get evaluated if I pass P around. The uneval-quotes in the that typeset snippet are inadequate for preventing literal f from becoming its assigned value, if P is fully evaluated. (This is the kind of trouble we get for having nested unevaluated function calls as a plotting data structure...) I can prevent such an accident by using Typesetting:-Typeset(sqrt(f)) or the InertForm variant, instead of the ephemeral 'sqrt(f)'.

@Rouben Rostamian  There are many useful exports of the Typesetting package which are not documented.

I don't know why that is so, since it's a useful and powerful package. It provides a major part of the Library side functionality for constructing a representation of expressions (used internally) that gets rendered by the GUI as 2D Math.

The Typesetting:-Typeset command is one of the (conceptually, functionally) higher level exports in that package.

As a procedure, it has special evaluation rules on its parameter expr. In consequence, if you call Typeset on a name, say nm, to which you've assigned some expression then Typeset(nm) will just type-set that literal name. One can get the underlying, assigned expression type-set by invoking it as, Typeset(EV(nm)) where Typeset and EV are both exports of Typesetting.