@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

Someone keeps removing all the tags on this Question.

Please stop doing that.

It's data that has a use (to Maplesoft). If this is a deliberate action (repeated four or five times now), then the member's ability to edit tags might itself need revising.

Try it without special characters like & in the file name.

If all that's needed are the plots then it seems as if one might add an option like,

    epsilon=1e-4

to the Int calls. I suspect that, or 1e-3, would retain decent visual accuracy while being quicker.