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

GraphTheory:-EigenvectorCentrality(G)

is equivalent to

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

The help ?algsubs does indeed describe this situation ("negative powers"), and an example shows how to workaround this restriction.

If subs or eval works, you should use them; subs is simplistic, whereas algsubs is very complicated.

a:= (n::posint, x::algebraic)-> if n=1 then x else sqrt(x*thisproc(n-1,x)) fi: 
a(100, 2);
 

The following process works regardless of whether the equation is linear or constant coefficient. The order of the differential equation will be the number of constants, let's say n. We take the original equation and its first n derivatives and eliminate the n constants from those n+1 equations, leaving 1 residual equation, which is the answer that we want. The general Maple command for finding such algebraic relationships is eliminate. So, this simple program does the job:

EliminateConstants:= (f::`=`, C::set(name), x::name)->
    eliminate({seq(diff(f,[x$k]), k= 0..nops(C))}, C)[2]=~ 0
:

The 2 near the end  is because eliminate returns the residual equation in the second position. It returns the solutions for the constants in the first position, but we don't care about those.

Usage:

EliminateConstants(
    y(x) = c1*exp(x) + c2*exp(2*x) + c3*exp(3*x), {c1, c2, c3}, x
);

The command currentdir can be used to set or view that folder name.

Like this:

sol:= W(x) = 
    _C1*(cosh(alpha*x)-sinh(alpha*x))
    + _C2*(cosh(alpha*x)+sinh(alpha*x))
    + _C3*sin(alpha*x) + _C4*cos(alpha*x)
:
V:= [sinh, cosh, sin, cos](alpha*x):
sol:= collect(sol, V, 'distributed'):
Coeffs:= (P, V)-> 
    local t, C:= coeffs(collect(P, V, 'distributed'), V, t);
    table('sparse', [t=~ C])
:
C:= Coeffs(rhs(sol), V):
subs([for k,t in V do C[t]=D||k od], sol);
  W(x) = D1 sinh(alpha x) + D2 cosh(alpha x) + D3 sin(alpha x)
     + D4 cos(alpha x)

The keywords distributed and sparse are not needed to for this particular problem. They're just there to make this code more re-usable.

interface(prettyprint= 0);

You need a multiplication symbol between (1-x^2) and (1-k^2*x^2).

This Answer is to provide a direct answer to your titular Question. I'm not posting this because I think that you should do permutations this way, but rather because passing and swapping pointers is particularly easy in Maple (especially Maple 2019 or later, as is coded below).

Procedure that swaps two pointers:

swap:= (a::evaln, b::evaln)-> ((a,b):= eval(b), eval(a)):
#Usage:
A:= 3:  B:= 7:
swap(A,B):
A,B;
                              7, 3

The evaln declaration (evaluate to a name) makes the procedure use the pointer rather than the value of the passed argument. The eval (evaluate) evaluates the pointer to its ultimate value. 

Procedure to swap (transpose) array elements:

ArraySwap:= (A::{Vector,Array}, i::integer, j::integer)-> 
    (A[[j,i]]:= A([[i,j]]))
:
#Usage:
A:= Array(1..9, k-> ithprime(k)):
ArraySwap(A, 3, 7):
[seq](A);
                [2, 3, 17, 7, 11, 13, 5, 19, 23]

Both of these procedures are simple enough that I'd likely just put the code inline instead of using explicit procedures. In particular, note that Maple's multiple-assignment operations do swaps without requiring any explicit intermediary variables.

You can include identical() in the typespec and initialize to () (both equivalent to NULL). Example:

P:= proc()
local a::{`=`, identical()}:= ();
    a
end proc:

Combinatorial objects can be generated one at a time with the Iterator package.

What purpose is served by using the inert form of Nabla in the composition? Why isn't (Nabla@@4)(f(x,y,z)) good enough for you? You can still make it inert by replacing f with %f.

Note that (Nabla@@4)(f(x,y,z)) = Divergence(Gradient(Divergence(Gradient(f(x,y,z))))) = 
((Divergence@Gradient)@@2)(f(x,y,z))

Hmm, this is a curiously simple Question for someone who's been on MaplePrimes for 6 years, so I hope that I'm not missing some subtlety. Anyway, 

P:= R*T/(V__m - b) - a/V__m/(V__m + b)/sqrt(T):
diff(P,T); diff(P, V__m $ 2);
 

Hmm. This is very bad, for the reasons that you metion. Apparently, the polymorphism doesn't extend to module names. There's a long-ago-deprecated module named process in your global namespace. You can do this:

my_car:-process(my_car);

I recommend that the object name be used as prefix in all cases simply to improve code readability if nothing else.

The fill value of the Array also needs to be of the specified type. The default fill value is 0, which is not of your specified type. So, do this

A:= Array(fill= sol, datatype= solution_class)