If I do it without Physics Updates, then there's no problem.

The type given as 2nd argument to subsindets can use a specific symbol by referring to it as identical(xi). So, this works:

S:= ex-> subsindets(ex, identical(xi)^integer, e-> H(op(2,e))*e);

Yes, the command is called maplemint.

Great point @sursumCorda ! That is something that I noticed and explained to my students on day 1 of the very first Maple class that I ever taught, some 25 years ago (2nd-semester calculus, freshman students with no Maple experience). Now that you've described the problem, I've thought of an easy solution that Maplesoft could implement: Put a flag on the status bar that indicates which of the following two things has occurred most recently:

1. the worksheet has been edited;
2. the worksheet has been sequentially executed with the Execute-Entire-Worksheet command.

This flag could be as unobtrusive as the single "*" that indicates whether the worksheet is unsaved.

Like this:

eval(expr, int= 1)

The output width of both lprint and showstat is controlled by interface(screenwidth). Its default value is 79, which I recall was a typical actual screenwidth in the 1980s. Modern screens are much wider.

There are many stumbling blocks that can occur when trying to time Maple commands, and I think that you've been fooled by one. For example, it's invalid to compare two measurements at least one of which has been rounded down to 0. The same is true for any measurements, even outside of computers.

The following example shows that using Horner's rule is much faster:

restart:
#degree, number of terms, and number of test-data points:
deg:= 2^6:  nterms:= deg+1:  nData:= 2^12:
p:= x^deg + randpoly(x, degree= deg-1, terms= nterms-1):
(P,Ph):= unapply~([p, convert(p, horner)], x)[]:
#Test data is rational numbers in fraction form:
Data:= `~`[`/`]('rtable(1..nData, random(), subtype= Vector[row])' $ 2):
gc(); Rh:= CodeTools:-Usage(map(Ph, Data)):
memory used=454.41MiB, alloc change=64.00MiB, 
cpu time=359.00ms, real time=702.00ms, gc time=93.75ms

gc(); R:= CodeTools:-Usage(map(P, Data)):
memory used=1.06GiB, alloc change=0 bytes, 
cpu time=3.28s, real time=7.22s, gc time=140.62ms

max(abs~(R-Rh)); #Check that results are identical.
                               0

There have been many innovations in Maple since Robert Israel wrote Factrix (circa 24 years ago). The following works for any rtable (i.e., vector, matrix, array), of any number of dimensions, whose entries are all exact explicit rational numbers (integers or fractions). It factors out the largest possible constant such that the remaining rtable is all integer.

Factrix:= (M::rtable)-> 
    (C-> `if`(C=0, M, C %* (M/~C)))(((igcd@op@numer~)/(ilcm@op@denom~))({seq}(M)))
:
Factrix(b);  #b is the matrix from the original question.

This is not meant to be a complete replacement for the original Factrix because this only handles rational numbers.

The first step is to adjust the functions that you want to plot so that they return an extended_numeric value for all numeric inputs from the plot intervals (alpha= 0..1, delta= 0..1). There's no need for you to understand the subtle distinction between numeric and extended_numeric. You just need to know that undefined is an extended_numeric value that all plot commands can handle gracefully. Currently, diffrP1 and diffrP2 return errors over a large portion of the plot intervals. Most plot commands can handle those errors and can convert them to undefined, but this doesn't work very well when you're trying to indicate the max of the 3 functions.

Here is how to trap the errors and convert them to undefined:

for k to 3 do
    DiffrP||k:= subs(
        _D= diffrP||k,
        proc(a,d) try _D(a,d) catch: undefined end try end proc
    )
od:

It is simply defining 3 new functions that call the original 3, "catch" any errors, and return undefined in those cases.

This next command plots those 3 functions in side-by-side plots. This is not strictly necessary for your final plot, but it'll help you understand it.

plots:-display(
    plots:-densityplot~(
        `<|>`(DiffrP||(1..3)), 0..1, 0..1, title=~ ["diffrP"||(1..3)],
        labels= [alpha, delta], labeldirections= ["horizontal", "vertical"],
        colorstyle= SHADING
    )
);

I've omitted a direct display of those plots here.

Finally, we create a new function that returns either 1, 2, or 3 to indicate which of the functions returns the maximum value and excludes undefined from consideration. A simple way to write that new function is 

max[index, defined]@[DiffrP||(1..3)]

And we plot it like this:

plots:-densityplot(
    max[index, defined]@[DiffrP||(1..3)], 0..1, 0..1, 
    labeldirections= ["horizontal", "vertical"], labels= [alpha, delta],
    scaletorange= 1..3, colorstyle= SHADING
);

So, the third function is usually the maximum, and there are small regions where the first or second are the maximum. 

The colorbar on the right of the plot was a feature introduced in Maple 2023. Without having the bar, you just need to know that red = 3, white = 2, blue = 1.

[The title refers to the seq parameter modifier, not the seq command.]

Addressing your question about why this inconsistency exists: I guess that a large part of the reason is that applyrule is many years older than parameter modifiers. I'd guess about 10 years.

Another method is to plot the inverse function using interchanged axes. Maple's solve and plot commands make that much easier than it sounds.

plot([solve(y = x^(1/3), x), y, y= -2..2], labels= [x,y]);

If you know the inverse, you could do

plot([y^3, y, y= -2..2], labels= [x,y])

Some adjustments to the1st method are needed if the function isn't injective on the desired interval and solve returns multiple inverses.

Like this:

Sum((-1)^r*x^r, r= 0..infinity)

My code below creates two procedures: LmR converts a set or list of equations and expressions to all expressions; Eq0 converts it to all equations. The key part is selectremove, which separates the input into two subgroups: the equations and the expressions. Then one of those subgroups is converted as desired, and the other is passed through unchanged.

(LmR,Eq0):= subs~(
    _M=~ [(E,A)-> ((lhs-rhs)~(E)[], A[]), (E,A)-> (E[], (A =~ 0)[])],
    (S::{set,list}({`=`,thistype}(algebraic)))-> 
        `if`(S::set,`{}`,`[]`)(_M(selectremove(type, S, `=`)))
)[]: 
ex:= {a*x^2 + b*x = v, c*x^2 + d*x - w}:
LmR(ex);
Eq0(ex);
                /   2               2          \ 
               { a x  + b x - v, c x  + d x - w }
                \                              / 

              /   2               2              \ 
             { a x  + b x = v, c x  + d x - w = 0 }
              \                                  / 

Note the role of the added variable z below. It is the objective to be minimized, and it's constrained to be greater than or equal to all of the linear expressions from your original objective. Thus it's greater than or equal to their max. By using an extra variable in this way, the objective and constraints are all linear. Having max directly in the objective makes it nonlinear, which is much more complicated to solve. The Optimization package doesn't handle nonlinear integer programs.

Your X should be an array of symbolic variables. Do not give it a datatype

Download firstworkablecode.mw

Surface is not a command per se; rather, it's just a token for parametirically specifying the surface of integration for the SurfaceInt command. The help page ?VectorCalculus,SurfaceInt has the complete instructions for specifyting a surface with Surface in the 4th paragraph of the 2nd bullet point of "Description".