Like this:

restart:
expr:= 
    (-x + sqrt(9*x^2*exp(2*c) + 8)*exp(-c)+99)/(4*x)
    + (a*sqrt(z)-99+sin(c*sqrt(r+4)+20))/3 
    + 10
    + 1/(c+exp(-x)*sqrt(exp(x)))
    + sqrt(h)
:
sq:= anything^{-1/2, 1/2}:
subsindets(
    subsindets(expr, sq, e-> _O*e), 
    And(`*`, satisfies(e-> membertype(sq, {op}(e)))),
    e-> LargeExpressions:-Veil[Z](eval(e, _O= 1))
);

The product of two or more types is not a valid type. That was the cause of your error.

Also, the :: operator has higher precedence than *, so the expression that you used with applyrule needs some parentheses (although I don't know whether that alone is enough to make it work (and I don't really care)).

This display is quite unfortunate!

In a Maple worksheet (I mean not in a tutor), enter

Eval(Diff(ln(x), x), x= x/2);

Observe the output. Do you understand what that output means, especially the part with the vertical bar and the equation written small on the lower right of the bar? Let me know. That same vertical bar appears in the tutor output, but unfortunately it's much shorter than would ever be used in typeset mathematical notation.

Now consider the subexpression Diff(ln(x), x) of the above, which stands for "the (inert) derivative of ln(x) with respect to x." By inert, I mean that it expresses the intention to calculate a derivative without actually doing it. The inertness is just used to make the steps more clear; the derivative is of course computed in a later step. In this subexpression, the x (in both occurences) is what computer scientists and logicians call a bound variable and what mathematicians sometimes call a dummy variable (a term that makes me cringe). This means two things (in this case): 1) That x could be temporarily replaced by any other pure symbolic variable (a variable that has no assigned value); and 2) That x cannot be replaced by something other than a variable, such as a number. So, the tutor's author has decided that the exposition would be clearer if that x were temporarily replaced by _X0. I find this to be an unfortunate choice, but note that this is just another variable and the underscore has no computational meaning; it's just like any other letter in a variable name. When a Maple programmer makes up a variable that will appear in output, they usually begin its name with underscore (this is just a widely followed convention; Maple itself could care less), although these underscores can cause confusion to new users. For use in a calculus tutor, I think that u would've been a more understandable choice.

Have you learned yet the "chain rule" for derivatives? It's the rule for the derivative of compound functions such as f(g(x)). Specifically it says that the derivative with respect to x of f(g(x)) is f ' (g(x))*g ' (x) or in Maple notation
Diff(f(g(x)), x) = Eval(Diff(f(u), u), u= g(x))*Diff(g(x), x) 
In your tutor example, this rule is being applied to ln(x/2) with f(u) being ln(_X0) and g(x) being x/2.

Your usage of a*b is problematic because of this:

has(a*b*c, a*b);
                             false

Neither your solution nor Kitonum's nor nm's will work if your expression contains a*b*c. So, I'd do this:

select(t-> has(t,a) and not has(t,b), [op](_x+f));

The _x is needed in case f is a single term.

You can use cat to create a list of every possible one- or two-letter Excel column label in order like this:

my_alph:= [seq](cat(("A".."Z")$k, 1), k= 1..2):
27*26 = nops(%); #for verification only
                           702 = 702

Like this:

expr := piecewise(x(t)<0, -1, x(t)<1, 0, 1) + f(t) + 
    piecewise(t<0, 0, t<1, 1, 0) + 
    x(t)*piecewise(t<0, 1, t<1, 0, 1) + 
    a*piecewise(t<0, 3, t<1, -1, 2)
:
OneVarPW:= proc(e::`+`, t::name)
local 
    v:= indets(e, And(name, Not(constant)))
        union 
    op~(0, indets(e, typefunc(anything, And(name, Not(mathfunc)))))
;
    select(hastype, [op](e), specfunc(freeof(v minus {t}), piecewise))
end proc
:
OneVarPW(expr, t);

In Maple 2021, typefunc(anything, ...) can be abbreviated to typefunc(...). I don't know whether this can be done in Maple 2015.

Type freeof is essentially the negation of type depends. My formulation above excludes all possible "variable" names other than t and mathfuncs whose arguments only depend on t. A "mathfunc" is one of Maple's standard defined functions (sin, ln, GAMMA, etc.). So, my formulation doesn't require your x to be specifically mentioned; since x is neither t nor a standard function name, both x(t) and "naked" x are excluded.

Note that if T is anything other than anything or NULL, then
select(hastype, ..., specfunc(T, piecewise))
cannot be replaced by
select(has, ..., piecewise),
as was possible for Preben's Answer.

Here is how you can get a package to automatically load all of its subpackages when it is loaded. My method is simpler than VV's in the long run because nothing needs to be changed as new subpackages are added:

restart;
OM:= module()
option package;
export
    IM:= module()
    option package;
    export add_three:= x-> x+3;
    end module,

    init:= proc($)
    local p;
        for p in exports(thismodule) do
            if thismodule[p]::':-package' then
                parse(sprintf("with(OM:-%a);", p), ':-statement')
            fi
        od;
        return
    end proc
; 
end module
:
with(OM);
                           [IM, init]
add_three(5);
                               8

Notes on that code:

1. The procedure must be named init, and it must be an export of the main package. If such a procedure exists, it'll be called automatically when package is loaded with with.

2. An init procedure is similar to, but not identical to, a ModuleLoad procedure. The former is called automatically when a package is loaded with with, while the latter is called automatically when a module (regardless of whether it's also a package) is read from a library.

3. The encapsulation of the with commands as strings executed by parse bypasses the usual prohibition against using with inside procedures and modules. Executing with parse is the same as executing at the top level.

4, My init requires no foreknowledge of the names of the subpackages nor of their exports. Indeed, it would be safe to keep it even if there were no subpackages.

5. My init can be used nearly verbatim in any package. The only thing that would need to be changed is the single occurence of the name of the outer package.

Here are two ways: nested piecewise or boolean combinations of the conditions:

f1:= piecewise(
    x<0, 0, x<1, piecewise(y<0, 0, y<1, x+y),
    x<2, piecewise(y<0, 0, y<1, x-y)
);

f2:= piecewise(
    Or(x<0, y<0), 0,
    And(x<1, y<1), x+y,
    And(x<2, y<1), x-y
);

Edit: Corrected direction of inequalities.

Here's an easy correction to your procedure:

LT:= (e::algebraic, t::algebraic)-> select(has, e + _x, t);

And, even better, make _x local. In Maple 2019 or later, that can be done in one line as

LT:= (e::algebraic, t::algebraic)-> local x; select(has, e+x, t);

You should keep in mind that has does a "deep" search. For example, 
has(y*sin(1/(1+f(t))), t) returns true. If you'd prefer a breadthwise-only search through the operands of the term, let me know. 

Yes, modules and procedures are first-class objects (see Wikipedia article) in Maple, meaning they can be placed anywhere any other expression can be placed. In contrast, libraries are not first-class objects.

Your usage of unapply is quite awkward, although I understand (from your Reply to mmcdara) why you did it. However, it's not needed: Create u as an expression, not a function, then subs for the X__4 or X__2 when that's syntactically required for integration or summation.

The symbolic integration and summation of all 800 terms is trivial, and can be done in 0.3 seconds:

u:= exp(-(X__4-Lmu)^2)*exp(-(X__2-Wmu)^2):
U:= CodeTools:-Usage(
        sum(int(subs([X__4= 5*k, X__2= x], u), x= -1..1), k= 1..800)
):
memory used=18.21MiB, alloc change=67.01MiB, 
cpu time=266.00ms, real time=264.00ms, gc time=15.62ms

The limits of integration could be made symbolic also. The entire integrated and summed expression above simplifies to 

sqrt(Pi)/2*(erf(Wmu+1)-erf(Wmu-1))*Sum(exp(-(Lmu-5*k)^2), k= 1..800);

Conversions between lists, sets, sequences, tables, and rtables are a constant requirement of Maple syntax; there's nothing special about the plotting commands that you mentioned. There's some such conversion in nearly every line of code that I post on MaplePrimes. Perhaps you'd feel better about it if you didn't use the lengthy syntax that you do. The conversion of an rtable R to a list requires only 7 additional characters:  [seq](R).

The code below creates and solves the same matrix-vector sys as you had. Together, that takes 1 line of code. Then it produces all 3 plots that you specified using [seq](sys) and the exact arguments that you used plus a title for each. The entire thing, including tab indentation and newlines, is 267 characters. (To contrast that, this paragraph has 362.)

restart:

V:= [x,y]; F:= <V(t)>; sys:= diff(F,t) - <1,2;0,3>.F; dsolve(sys);

for P in [dfieldplot, phaseportrait, DEplot] do
    (print @ DEtools[P])(
        [seq](sys), V(t), t= 0..4, 
        `if`(P=dfieldplot, [][], [V(0)=~ [1,0]]), V[]=~ -4..4, 
        title= sprintf("DEtools:-%a", P)
    )
od;

The command implicitdiff handles this. See its help page, ?implicitdiff.

A procedure for it:

MROUND:= proc(X::realcons, m::posint)
local x,r;
    if X<0 then return -thisproc(-X, m) fi;
    x:= trunc(X);
    r:= irem(x,m);
    if r + frac(X) < m/2 then x-r else x-r+m fi
end proc
:

This bug seems to be the result of a bit of arrogance on the part of the author of SolveTools:-CancelInverses. Look at lines 65-66. That person believes that there is an intermittent bug in simplify such that sometimes it returns expressions with a free _Z (which has been extracted from a RootOf). And, there may in fact be such a bug, but, if there is, it plays no part in the current example. The arrogant part is that that programmer does not check whether the expression had a free _Z before it was passed to simplify. Indeed, in this case, the expression has a free _Z even at the point that it's passed to CancelInverses. This makes it particularly easy to write a workaround for this bug:

restart:

interface(warnlevel=4):
kernelopts('assertlevel'=2):

CI__orig:= eval(SolveTools:-CancelInverses):
unprotect(SolveTools:-CancelInverses):
SolveTools:-CancelInverses:= overload([
    proc(e::satisfies(e-> depends(e, _Z)))
    option overload;
    local _A;
        eval(CI__orig(eval(e, _Z= _A), _rest), _A= _Z)
    end proc,

    CI__orig
]):
protect(SolveTools:-CancelInverses, CI__orig):

expr:= exp(x)*sin(y)-3*x^2+(exp(x)*cos(y)+1/3/y^(2/3))*Z = 0;
solve(expr, y);

The representation z <= sqrt(-x^2-y^2+9) of a hemisphere is in cartesian, not spherical, coordinates. So, if you remove coords= spherical, you'll get something better. But I think that this is even better:

plots:-display(
    plot3d(
        [3, theta, phi], theta= -Pi..Pi, phi= 0..Pi/2,
        coords= spherical
    ),
    plot3d(
        [r, theta, 0], r= 0..3, theta= -Pi..Pi, coords= cylindrical
    ),
    scaling= constrained
);

I think that's it's only really possible to plot surfaces, not solids. So, in the above, I "capped" the bottom of the hemisphere.