@Ronan It's a pity you didn't show or explain what you actually wanted to accomplish when you first posted your Question.

I think that declaring variables `global` like that is not great programming.

You could achieve the same behavior by merely adding to my example's module a new export procedure which reassigns values to the module locals Cartvars and Parmvars. That's a rather usual approach.

ps. Some benefit of modules is encapsulation, and protection of the global name-space.

@dharr In Maple 2026.0 one could just,

   convert(simplify(expr), cosh)

as there the result of simplify(expr) is  1/4*sech(1/2*u)^2  . That's also the case for the OP's other original expression, exp(u)/(1+exp(u))^2 .

note: In Maple 2024.2, as opposed to taking reciprocals, one could get to  1/(2*cosh(u)+2) by simplify(combine(expr)) .

@Alfred_F The first step below (with the reciprocal) speaks to another weakness in simplify. One might reasonable hope that simplify(expr) would do that directly.

Download test2_ac.mw

@Rouben Rostamian  I could add that the redraw=false option could also be added to (just) the plots:-display call. Although the plots:-display might occur in some code not written by you, in which case adding it to the plot call could serve.

Btw, the fact that additional curves (when merged) may redrawn with different colors is mentioned in the plots:-display Help-page, and also noted on the Maple 2022 compatibility page. But it seems (to me) to indicate that one might supply redraw=false to plots:-display only, rather than (alternatively) to plot itself.

nb. coords=elliptic (or other) doesn't have a corresponding setting for the axiscoordinates option. But your issue occurs for that too.

A milder effect can occur when some reduced domain determination occurs in the individual plots. Eg,

p1:=plot(5^x,x=0..20):
p2:=plot(6^x,x=0..20):
plots:-display(p1,p2)
plots:-display(p1,p2,redraw=false)

I added all this as notes in the report.

It works ok in Maple 2021, but not in Maple 2022-2026.0, it seems.

Of course, the behavior you've shown is wrong. It's supposed to automatically combine the x-ranges into the larger union.

The bug shows up with that use of the coords=polar. Without that the x-ranges are combined as expected, without needing to supply a view.

I can submit a bug report against what appears to be a regression.

By the way, if you don't want to specify explicitly the y-range in the passed view then you could pass the option as,

     view=[-2..2,default]

in which case it will inherit. I write that just to correct the 3rd bullet point, apparently from AI, in nm's Reply.

And if the AI also claims that the view option is needed in such examples then it'd be confused about that too.

note also:

eval( tan(x)-sec(x), x=Pi/2 );
Error, (in tan) numeric exception: division by zero

limit( tan(x)-sec(x), x=Pi/2 );

           0

@C_R 

Btw, while I used value for most of the example checks, I threw in one with a call to simplify instead, to illustrate its effect.

I'm a bit on the fence about whether it's mostly a good thing that this next example returns zero.

    simplify( sqrt(2) - %sqrt(2) )

Also, the following will return 2*3^(1/2)

   simplify( %sqrt(12) )

So I'm not sure what gemini means by its claim that "Simplification" is "Blocked". It doesn't seem to be a claim about "Evaluation", which has a separate line in what you showed. Perhaps it's just some sort of claim about immediate arithmetic cancellation (though, logically, that seems just a consequence about lack of immediate evaluation).

ps. evala and radnormal seem to leave %sqrt alone. And they can do a kind of simplification.

@C_R That's really interesting.

Except for perhaps one minor spot ( about explanation of [op(u)] vs [u] ) it seems like an accurate explanation, broken into steps properly. Up until the point that it misinterprets %sqrt, of course.

I wonder how it might ever learn that %sqrt is an inert form.

The explanation made a weakness apparent to me: the denominator of the content might not be numeric.

M := 1/(11*Q(sqrt(5)));

    1/11/Q(5^(1/2))

C := content(M);

    1/11/Q(5^(1/2))

irem(C, 11);

   irem(1/11/Q(5^(1/2)),11)

rem(C, 11, ':-__x');

         0

And so I tentatively offer a revision that also handles this additional example:

Download unrat02b.mw

This is a benefit of trying to concoct "unit test" examples, and trying to find examples that "break" your code.

ps. There is some dodginess to using rem here. But I haven't thought of the fatal counterexample yet. ;)  And I know that I can't just handle the numerator the same way (tempting as may be).

Looking at the code in the routines, it seems to me that (perhaps since at least Maple 2021) the passed option prolog=true might be simply disregarded.

If that's true, then the change in Maple 2026 is merely that passing it throws an error. But if it was simply ignoring it previously then one solution now is to stop passing it in one's code.

You could allow it through the first few layers (see below), but once inside XMLTools:-NSXML:-ParseFile it seems simply to be ignored, and that's seems true of even the deeper level
XMLTools:-NSXML:-Parser:-parseFileImpl routine.

I don't really see the point of doing this, but that's why I asked for an input file where passing prolog=true make it return some different result (and without emitting an error).

Download xmlparse01.mw

@nm You seem to have linked to this same page, rather than to some older Question thread.

It looks as if the $ terminator has been added at the end of the parameter specification of,
    XMLTools:-NSXML:-ParseFile
which means that it's only accepting explicitly specified parameters (which doesn't include, say prolog::boolean).

Do you have an example of an input file for which option prolog=true passed to ParseFile made a concrete difference in some earlier Maple version?

ps. I have a hazy recollection that the internal parser being used by ParseFile may have been switched at some point in the past. But I don't know whether it might have just silently ignored prolog=true after that.

What would you want to happen to, say,

    sqrt(2)/14?

Would you want it to become

    1/(7*%sqrt(2))

?

limit(S2, c__1=infinity);

     y(x) = x exp(2 Pi)

odetest(%, ode);

           0

@C_R On Linux the users Favorites palette items are stored in a file separate from the GUI preferences file.

On Linux (at least), it is a file named   Favorites.properties

Perhaps you had such a file from an earlier version (say, 2025) under your Maple folder,
    C:\Users\<User ID>\AppData\Roaming\Maple
and that got imported into your new Maple 2026 installation even though you did not import the other maple.ini regular GUI preferences file.

@C_R That's really great to hear, that you're up and running ok.

If it's not too much trouble, could you please send both your Maple 2025 and the problematic "imported" Maple 2026 maple.ini preferences file (suitably renamed, say) to tech support. I can imagine that a GUI developer might be interested in trying to deduce what went awry.