I agree that it is a bug, the behaviour is at odds with the Description on the ?convert,Vector Help page which states that the default orientation is column.

I notice that Description says that an Array or list would each be passed straight to the Vector constructor. But notice the following difference in behavior (which appears to be the explanation of the behavioral side of the coin here):

It's possible that the person who wrote the ?convert,Vector Help page overlooked the fact that no single orientation satisfies that act of passing some structures straight to the constructor; ie. it varies by nature of the argument. It's even reasonable that someone might deem the appropriate fix to be to amend that documentation and retain the current behavior.

Having said that, I usually prefer do that kind of thing like,

    Vector[column](A);

I also convert-to-Matrix in a similar manner. Those constructor calls preserve datatype which is often quite important to me, and also storage=sparse (which, while much rarer for me, is something I'd often prefer my code respect by default unless I was deliberately coding to clobber it).

For example, if I had a list L I'd convert it to a Vector with,
    Vector(L)
rather than,
    convert(L,Vector)
which is both longer as well as (for my purposes, often) inferior. Similarly I'd handle a listlist LL with,
    Matrix(LL)
rather than,
    convert(LL,Matrix)

nb. In other words, I'd prefer to call the constructor directly, rather than write out a convert call which is more verbose while getting to the same act. I see less merit in calling convert in many such situations.

This was reported by someone else a little while ago, also for Maple 2025.

You might need to wait for the 2025.1 point-release, to get a GUI-update that fixes this.

(I do not believe that this can be fixed by a pure Library-side change, eg. in SupportTools).

That's the way it is, for 3D plots.

For 3D plots, the GUI places the largest "square" inside the inline plot window (the thing that has resizable borders, when you place the mouse focus on the plot). The `size` option only specifies the dimensions of the inlined plot window, and has no effect on the aspect ratios between the three extents of the displayed axes. I believe that the design intention is to allow the full plot to remain fully visible upon any manual rotation angles.

It is possible to use the DocumentTools package to embed an inline plot with the zoom factor programmatically specified. This can give the effect of stretching (only) horizontally, without the wasted white space above and below. If you look at the InlinePlot call in the very last example here ( Help Topic ?DocumentTools,Components,Plot ) then you can see such a programmatic zooming effect in which a long, short 3D thing is plotted without wasted vertical white space. (The effect is better see if you run the example in your Maple; the online Help page's rendering muddies the effect.)

The idea here is that the size option forces a long&short inlined plotting window, and then the rendered 3D plot seen through that window is forcibly zoomed in. That's the only way I know, to get such an effect programmatically at present. Another example, here.

Let us know, with an actual example, if you have trouble getting that effect to work for you. nb. I also don't know whether the effect maintains properly, on Close & Reopen of the sheet.

I've wanted 3D axes aspect ratios, as programmatic options, for some time now. But, in their absence, you're left with the choice of either unconstrained scaling (ie. all-equal aspect ratios) or a poor man's (still not fully satisfactory) effect if you manually rescale all your plot data/functions to mimic the desired aspect ratio.

The OP has encountered a common usage difficulty for users new to Maple.

In summary,
i) Using unevaluation quotes to delay the evaluation of the first argument works here, but is not the best general solution. Yes, it works for this example. But I've seen this usage devolve into even murkier difficulties far too often.
ii) Using irem vs modp happens to work for this example (and can have better efficiency) but is not by itself the best general solution because many similar difficulties arise for problems having nothing to do with modp/irem.
iii) The add command is more appropriate that sum here. It's specifically designed to better and more more generally handle this kind of issue. Yes, it's unfortunate that the 2D Input Sigma symbol is hooked into sum rather than add. But the allure of the typeset Sigma notation doesn't generally make up for the shortfalls of using sum in such situations.
iv) Similar distinctions can arise with product vs mul.

Altogether,
    add(irem(5, mul(2, t = 0 .. irem(q - 1, 3))), q = 1 .. 2)

And now, for some details,

Download sum_add_eval.mw

This is a common issue for new Maple users. There are lots of examples of this kind of problem on this forum.

There are also several Help Pages devoted specifically to the issue: eg,
1) special evaluation rules
2) sum vs add

Does this work for you? (Check that it makes good sense. It's late in the day...)

Download how_to_verify_parametric_solution_to_ode_ac.mw

You have defined the substitution equation T1 as,

   T1 := u(x, t) = U(-t*v + x)*exp(k(t*w + x)*I)

where you are missing a multiplication symbol between the k and the opening bracket. That gives you a function call k(t*w + x) , ie. a call to unknown function k. When you then substitute into the derivative wrt t the chain rule applies, and you get D(k)(...) terms.

You may have intended, instead,

   T1 := u(x, t) = U(-t*v + x)*exp(k*(t*w + x)*I)

Download tr_ac.mw

Is this something like you what you're after, without the fractions? (Below are two ways, for this example)

Download B-R_ac.mw

> restart;
> kernelopts(version);
   Maple 2025.0, X86 64 LINUX, Mar 24 2025, Build ID 1909157

> A := -x*(x - 4*exp(x/2) + 2):
> B := x*sqrt((-8*x - 16)*exp(x/2) + x^2 + 4*x + 16*exp(x) + 4):

> simplify(simplify(A-B, {exp(x)=exp(x/2)^2})) assuming x::real;

                    0

Another way to forcibly attack the issue,

Download nm_simp_exA.mw

Naturally, many such temporary replacements may be constructed in an ad hoc manner. How well the system might be taught to do it automagically, I don't know.

Download inert_gt_latex.mw

You posited, "It seems Maple like to make everything  based on "<" internally and that is why it reverses it?". Yes.

You can easily form a similar rule to sustitute in the reciprocals. And you could also use both within the single subs call, to avoid having to distinguish which is present (or even if both are present).

Download subs_ac.mw

One fault seems to be that the derivativedivides method fails for integrand_2, while it succeeds (and produces that simpler result) for integrand_1.

A second fault is that int returns the result with ln and I=sqrt(-1) (which can obtain from the risch method) for integrand_2 instead of returning the better result from the orering method. The orering method's result is longer, but doesn't contain I or ln, and can be simplified directly to the short result using merely the normal command.

Download int_weakness_02.mw

There are at least two parts to this Question.

1) Your evalf (at default Digits=10 working precision) does not produce 10 accurate
digits of an apprximation of the second exact root obtained by solve. Substituting
the poor root approximation happens to also produce zero in the denominator.
But substituting a more accurate approximation happens not to.

2) Your plotting problem is the same as in one of your earlier Questions from today. (This site has faulty inlined display of the worksheet below, but my actual worksheet contains the adaptive=true and smartview=false options.)
 

Download plotq_ac.mw

The small imaginary components of your result can be seen to be an artefect of solving a cubic in terms of radicals, and then computing as a floating-point approximation (in which case the small imaginary artefacts don't vanish due to floating-point concerns -- roundoff error, loss or precision, etc).

You can read about the notion that the purely real roots of some cubics may not be expressible in terms of radicals without the "I" (ie. sqrt(-1)) being present. But a reformulation in terms of trig expressions can get a form in which "I" does not appear, and for which floating-point evaluation produces no such small imarginary artefacts.

Download concentrations_ac.mw

I marked your Question to be Product=Maple 2022, since that's the version in which your attachment was last saved. It'd be more helpful if you could mark the Product version yourself, for future Questions.

In Maple 2022 your examples are running into issues with the (then new) adaptive=geometric default, and/or the default smartview=true option. Some improvement might be had automatically in the newer Maple 2025.

Each of your examples can be forced to comply (in versions M2022 to M2025) by adjusting those options:

Download plotatzero_ac.mw