I will submit a bug report against this regression in behavior in Maple 2026.

It seems to me that the problem might occur only if the filled (or filledregion) option is supplied.

In the meantime I'll note that the orientation can be otherwise specified in a wrapping call to plots:-display. Apologies if you were already aware of that, and naturally there's still a bug. Eg.

with(plots):

display(contourplot3d(-x/(x^2+y^2+1),x=-3..3,y=-3..3,filled),
        orientation=[90,45,45]);

What don't you simply put all your very recent and highly related Posts on this into one single Post?

Five Posts with closely related prime number code in them, in less that 48 hours, seems a bit like spam. I've deleted several of them.

If you want to add the contents of the others to this one Post here, and followups, please go ahead.

@C_R The `Compare` procedure's special evaluation rules, ie. VV::uneval for its second argument, combined with the special way Equation Labels are handled (so they don't prematurely evaluate, say), is producing an effect that you don't like.

Contrasting with the behavior that happens when you pass the input, literally, isn't a very sensible comparison, in light of that.

Conflating proc parameter specifier ::uneval and constructor uneval(...) isn't very helpful here, as they are not identical.

See also my previous comments about Equation Label evaluation quirks.

You have been shown three working approaches, including the documented one(!) of passing Compare the extra option. See my Answer.

If you feel that there's a GUI/kernel bug, you should submit a report.

@C_R I don't see any evidence that what was happening was that the kernel didn't know to which output you referred.

I do see confusion about evaluation concepts, in what was attempted in your worksheet, etc.

Equation Labels have some evaluation quirks, partly due to the GUI/kernel/Typesetting-parser trying to get them to behave like literal input (or as close to that as possible). It seems difficult to get it quirk-free, and their behavior in some circumstances has change slightly ovet the years, as buggy cases have been adjusted.

@C_R If you call   uneval((2)[1])   for your Expression Label  (2)  then the indexing selection evaluates up front.

Perhaps you wanted  uneval((2))[1]  , which would apply the quotes, and then the indexing.

Using an expression sequence assigned to a name,

foo:=a,b: uneval(foo)[1];

              'a, b'[1]

@dharr It works now because I fixed the link. (Originally, if was a local link like file:::/... ie. a link to a local file on the responder's machine. I replaced that with an arxiv.org URL I located.)

@sursumCorda That difference in evaluation is interesting, for some versions more recent that the original Maple 2020.

When calling convert on an active (but unresolved) int call, I am used to the integration being re-attempted on the converted integrand. I'll likely look into when and why that evaluation aspect changed. It could simply have been a correction, for consistency with other convert behavior.

The following do work in my Maple 2026.1,

int(convert(arccos(x)*arcsin(x),arcsin),x);

eval(convert(int(arccos(x)*arcsin(x),x),arcsin));

int(convert(expand(convert(arccos(x)*arcsin(x),ln)),arctrig),x);

# That is, both these integrands work directly:
#  (1/2*Pi-arcsin(x))*arcsin(x)
#  1/2*arcsin(x)*Pi-arcsin(x)^2

And, of course, I agree that any forced method ought not to be needed. I believe that I subitted a bug report for this when it was first posted. I'll check my records.

@C_R The terminology on that Help page is not careful and precise. There are also some false claims. I will file a bug ticket.

This is an area where it serves to be precise, because we're throwing around technical jargon of a programming language, and ambiguity or imprecision can lead to confusion.

So, (and I offer this in the best spirit), it's not the case that `+` is "the name of a function". It's not quite right in a few different ways:
- More correct is that `+` is a name to which a procedure has been assigned.
- It's a procedure that's been assigned, not a function. (It's a good habit to strive to not use the word function to refer to a procedure/operator in a Maple context. It's too often confused with an expression. Better to reserve the word function for referencing the type function, ie. an unevaluated prcedure call.
- The same procedure can be assigned to more than one distinct name, and so it's not right to write of the name of a procedure (without qualification).

Also, I suggest that you shy away from using whattype. The type system is not hierarchical in a way for that to be a fool-proof inquiy mechanism. (I know, sorry, I've suggested this before.) Really good Library programs don't use it; they query explicitly for target types.

I realize that I'm sounding uptight here. I'm on a bit of a Documentation nit-picking kick.

Also, since we're having fun, some levity.

Quite often I find I want/need to see the static exports of an Object. For that I'd do, say,

   exports(df1, static)

If a DataFrame has 50 static exports then there's a decent chance that some collision is going to occur with a rebound name from some loaded package.  As another example, DataFrame static export Transpose and LinearAlgebra:-Transpose.  If one loads LinearAlgebra then the example Transpose(DF) breaks, but not if called as :-Transpose(DF) or DF:-Transpose(DF), etc, which is unlikely knowledge in the absence of documentation that the DataFrame DF is an Object.

But there you are... information hiding, abstraction, and hiding implementation details: key aspects of OOP, aka Principles of Object-Oriented Programming.

@C_R

Note that `+` is a name (which happens to be assigned a procedure). 

And so `+` + `+` automatically simplifies to 2*`+` , much as a+a automatically simplifies to 2*a.

By "automatically simplifies" I mean that is happens by automatic simplification, done before evaluation.  And that's not prevented by uneval-quotes, ie. 'a+a' also produces 2*a.

[edit] Here are some fun examples to study. There are two flavors of automatic simplification in the following examples:
1) name+name -> 2*name
2)  numeric * simple-poly getting the numeric coefficient distributed across the sum

More fun than a barrel of monkeys. I've written it somewhat back-to-front, in that some later examples might help explain some earlier examples.

Download auto_simp_functional_fun.mw

@C_R Your attachment cannot be downloaded since its file-name contains the special character "%".

@C_R You persist in mistakenly referring to it as if it were a single piece of self-contained syntax. Which it is not, as explained in my Answer & followup.

It's just two common syntax items used together: two different uses of parentheses, that happen to work side-by-side.

@dharr If one uses the form Physics:-diff(...) , or if one loads only the specific command by with(Physics,diff) , then one can avoid the full set of name rebindings for that package's exports that comes with the blanket operation with(Physics).

(eg. rebindings of `*`, `.`, Factor, Trace, Expand, etc)

@awass 

If you want to use the simple read functionality (for accessing/loading a value for a name, but only when you decide to, as an explicit action), then yes, the simplest way to update the stored value is to repeat the command,
    save p,q,r, "test.m";
which just clobbers the file "test.m", by replacing it. Yes, if you store multiple assigned names/values to the same .m file then it can be problematic to update them separately. It sounds as if using distinct .m files for each stored name might work best for your scenarios as described so far.

I forgot to mention something in my Answer. I made it sound as if you had to use fprintf if you wanted to store a plaintext readable file. But you can in fact use the save command store the polynomial, assigned to name p, as plaintext, in a text file. The differences comes from the choice of filename extension. The following command would also produce a plaintext file:

    save p, "foo.mpl";

whose contents could be just a single statement of text, as Maple code, like say,

    p := 62*x^9-82*x^8+80*x^7-44*x^5+71*x^4-17*x^2;

You could also do the same thing with, say,

    save p, "boo.txt";

That plaintext can be used with the read command. And in fact it's the very same plaintext that my Answer's second fprintf example constructed.

The .m extension (dotm) is a proprietary form, mostly unreadable without special knowledge. One of its virtues is that some large structures can be stored/accessed reasonably quickly. Another is that some non-text structures can be stored.

A more complicated mechanism is that of Maple Library Archives, which are files with .mla filename extension. Those are contained for multiple .m structures. It doesn't sound to me that (at present) you are in need of that extra complication. See the Help page for LibraryTools, if wanted. Not only is access quite different for that mechanism, but it's awkward for retrieval other than once-per-session for each name. And it uses libname, whose Help page mentions the older savelib & march rather than the newer (simpler/safer) LibraryTools. Sigh.

ps. Regarding loading of the plots package. Maple has many packages. Some different packages export the "same" name. But even without such inter-package collision, there are other reasons why packages are not loaded by default: they are a form of encapsulation; they preserve the global name-space.

@dharr That's nice. I vote up.

If you don't mind my following up on your suggestion for inert %Determinant, etc, (and a couple of edits),

Download ZehfussReplace_ac.mw