It's a mathematical convention that when an associative operator with identity is applied to 0 operands (i.e., an empty list of operands), then the return value is the identity of the operator. Compare the following in Maple:

`+`(), `*`(), `union`(), `and`(), `or`();
             0, 1, { }, true, false

The integral int(Dirac(f(x)), x= a..b) simply counts the roots of f(x) in the interval. Assuming that the roots are simple, f(x) is analytic, and a bound dI can be given such that it's known that the box z= a-dI*I..b+dI*I contains only real roots, then the roots can be counted by this simple numeric integration procedure:

RealRootCount:= proc(
    f::algebraic, X::name=range(realcons), DI::realcons:= 0
)
description `Counts roots of analytic function with multiplicity`;
local 
    x:= lhs(X), a:= lhs(rhs(X)), b:= rhs(rhs(X)),
    F:= unapply(diff(f,x)/f/2/Pi, x),
    dI:= `if`(DI=0, (b-a)/1e3, DI), opts:= ('epsilon'= 1e-3, _rest) 
;
    (round@`simplify/zero`@fnormal@evalf[trunc(evalhf(Digits))])( 
        I*Int(F(x+dI*I) - F(x-dI*I), x= a..b, opts) -
        Int(F(a+x*I) + F(b+x*I), x= -dI..dI, opts)      
    )
end proc
:
RealRootCount(sin(x), x= -3/2*Pi..3/2*Pi);
                               3

One-point assumptions such as variable= value are ineffective whether using assume or assuming. Perhaps a warning should be issued when they are attempted.

Instead, do

sol:= pdsolve(eval(pde, alpha= 0), build)

Your code is massively inefficient. One of many possible replacements is

T1:= table(sparse, L1=~[$1..nops(L1)]):
Threads:-Map[2](index, T1, L2);
[2, 3, 8, 12, 15, 0, 0, 0, 0, 0]

subsindets(expr, specfunc(exp), ()-> Z)

IMO, subsindets and evalindets are the most important commands for symbolic/syntactic processing.

If you want to sort^[*1] matrix A by its column C, then use

A[sort(A[.., C], 'output'= 'permutation')];

It doesn't matter whether the matrix is square.

[*1] To be more formal, I'd say "to sort the rows of matrix A using column C as the key, ...."

Ah, this procedure listpart was the very first thing that caught my attention as needing improvement in the lengthy worksheet that you sent me a few days ago. Assuming that nchunk is the number of chunks and that you'd prefer them as equally sized as possible, here's how I'd do it:

ListPartition:= (L::{list, set}, nchunk::posint)->
  local 
        j::thread_local,
        J:= Iterator:-SplitRanks(nops(L), 'numtasks'= nchunk)
    ;
    [Threads:-Seq](L[j[1]..add(j)-1], j= J)        
:
ListPartition([$1..30], 7);
    [[1, 2, 3, 4, 5], [6, 7, 8, 9, 10], [11, 12, 13, 14], 
      [15, 16, 17, 18], [19, 20, 21, 22], [23, 24, 25, 26], 
      [27, 28, 29, 30]]

Why does this bug occur? Somewhere in some child of radnormal, the large integer shown is factored. Here's its true prime factorization:

n:= 646162507019111437893207695980096110233782566593779:
CodeTools:-Usage(ifactor(n));
memory used=7.02MiB, alloc change=256.00KiB, cpu time=109.00ms, real time=142.00ms, gc time=0ns

(5415624023749) (70334392823809) (168749965921) (10052678938039)

We can see that Maple had no trouble (timewise) doing that. However, ifactor has an option easy (see ?ifactor) for very quick usage which gives just "small" prime factors multiplied by some variables that represent composite numbers. Some quick testing shows that the cutoff for what's considered "small" is about 1.3 million.

So let's see what this option does with our n:

CodeTools:-Usage(ifactor(n, easy));
memory used=24.45KiB, alloc change=0 bytes, cpu time=0ns, real time=2.00ms, gc time=0ns

                         _c27_2 _c25_2

This says that it knows that n is a product of two composite numbers---one with 27 digits and one with 25 digits---and it refuses to do more work than that under option easy. The _2s are just session-dependent serial numbers; you can see the _25 and _27 digit counts in your error message with different serial numbers.

Some child of radnormal must've called ifactors(n, easy) but was unprepared to deal with those symbolic composites.

The code of radnormal and its children is written in Maple (not built-in to the kernel).

An expression e(...) with no space after the e (in 2d Input) is processed as a function. So, in your examples, x is treated as a function symbol. When a number appears as a function symbol, it's processed as a constant function, which is why you get 1.

You were only a few steps away from the solution. Note that the GAMMA function is all uppercase and Pi is a predefined constant.

My style is a little different than Rouben's or Tom's with regard to := vs. =. I tend to prefer using fewer := and instead use eval[recurse] to consolidate everything in the dsolve step. But there's nothing wrong with their styles either!

ODEs:= 
    diff(U1(x),x)=-diff(phi(x),x)/(U1(x)-T/U1(x)),
    diff(phi(x),x$2)=
        (1+A1*phi(x)+A2*phi(x)^(3/2)+A3*phi(x)^2)-(M1/U1(x))
:
Evals:= {
    A1 = (2*k-1)/(2*k-3),
    A2 = 8*sqrt(2/Pi)*(beta-1)*k*GAMMA(k)/
        (3*GAMMA(k-0.5)*(2*k-3)^(3/2)),
    A3 = (4*k^2-1)/(2*(2*k-3)^2),
    M1 = 0.1+sqrt(T+(1/A1))
}:
ICs:= U1(0) = M1, phi(0) = 0, D(phi)(0) = 0.001:
Sol:= dsolve(
    eval[recurse]({ODEs, ICs}, Evals),
    numeric, parameters= [T, beta, k]
):
Sol(parameters= [T= 0.1, beta= 0.6, k= 3.5]);
plots:-odeplot(Sol, [x, phi(x)], x= 0..22);
plots:-odeplot(Sol, [x, U1(x)], x= 0..22);
plots:-odeplot(Sol, [x, diff(phi(x),x)], x= 0..22);

I'll call your constant C for brevity. Integrate the cases C < 0 and C > 0 separately, and use option method= FTOC (Fundamental Theorem Of Calculus) inside the int command. The two results will be very slightly different.

int(1/(1-C*cos(t))^(3/2), t= 0..2*Pi, method= FTOC)
    assuming -1 < C, C < 0;
-4/(C+1)^(1/2)*EllipticE(I/(C+1)^(1/2)*(-2*C)^(1/2))/(-1+C)

int(1/(1-C*cos(t))^(3/2), t= 0..2*Pi, method= FTOC)
    assuming 0 < C, C < 1;
-4/(C+1)^(1/2)*EllipticE(2^(1/2)*C^(1/2)/(C+1)^(1/2))/(-1+C)

SplitProduct:= (e::algebraic, t::name)->
local `1`; 
    eval([selectremove](depends, `1`*e, t), `1`= 1)[]
:

As far as I'm concerned, the entire *match family of commands are junk.

The updating assignment operators (such as ^=, +=, *=, and ++ used below) were introduced in Maple 2018. 

MyIntSum:= proc(n::nonnegint, ab::range(algebraic))
local a:= lhs(ab), b:= rhs(ab), ak:= a, bk:= b, k:= 1, k2:= 1, kf:= 1, S:= b-a;
    a^= 2; b^= 2;
    to n do S+= ((bk*= b) - (ak*= a))/(kf*= k++)/(k2+= 2) od;
    S
end proc
:    
evalf(MyIntSum(167, 5..10));
#Compare:
evalf(Int(exp(x^2), x= 5..10));

10-digit accuracy requires n > 167 (value found by simple trial-and-error experimentation).

MyContFrac:= proc(n::posint, x::algebraic)
local k, r:= x^n;
    for k from 2 to n do r:= x^(n-k+1) + x^k/r od;
    r
end proc
:  
MyContFrac(10, x);
 

Yes, they correspond as you suggest. Indeed, for any graph G,

GraphTheory:-EigenvectorCentrality(G)

is equivalent to

GraphTheory:-EigenvectorCentrality~(G, GraphTheory:-Vertices(G))