In the situation that you describe---"being unable to do anything (even 2+2)"---do the characters "2+2" appear on the screen as they are typed?

The coloring conditional can be simplified in a much more understandable way with xor, i.e., "exclusive or":

a xor b  iff  (a or b) and not (a and b)  iff  (a and not b) or (b and not a)

The evalf[4](evalhf(...)) is better handled by first making an hfloat Array and then rounding it to 4 decimal places:

restart:
RC:= (0..35, 0..9):
DocumentTools:-Tabulate(
    <
        <x, seq(nprintf(`#mi("%.2f");`, j/100), j= RC[2])>^%T,
        <
            <seq(nprintf(`#mi("%.1f");`, i/10), i= RC[1])>  |
            (evalf[4]~@rtable)(
                RC, (i,j)-> (1+erf((10*i+j)/100/sqrt(2)))/2, datatype= hfloat
            )
        >
   >,
   exterior= none,
   fillcolor= ((T,i,j)-> `if`(i=1 xor j=1, "LightBlue", "White"))
):

@Christopher2222 As far as I can tell, ToInert does nothing in your example, nor would I expect it to. The alias commands do all the work. Indeed, if ToInert did do something here, that would definitely be a bug, because it would mean that ToInert has an unintentional and undocumented side effect.

Here is your worksheet, which I've re-executed, and the only change I made was commenting out the ToInerts.
 

Download ToInert.mw

@sursumCorda The command ArrayTools:-Alias can be used to create a separate in-place pointer to an rtable (Array, Matrix, Vector) with a different dimensionality. So you can switch back and forth between matrices and vectors, whatever your commands prefer, with no copying of the data.

@jalal That's good.

You can get rid of the displayed quotes, get rid of interface, and simplify the coloring conditional like this:  

restart:
DocumentTools:-Tabulate(
    <
        <x, seq(nprintf(`#mi("0.0%d");`, j), j= 0..9)>^%T,
        <
            <seq(nprintf(`#mi("%d.%d");`, iquo(i,10,'r'), r), i= 0..35)> |
            Matrix((36,10), (i,j)-> evalf[4](evalhf((1+erf((10*i+j-11)/100/sqrt(2)))/2)))
        >
   >,
   exterior= none,
   fillcolor= ((T,i,j)-> `if`(i*j = 1 or i*j > max(i,j), "White", "LightBlue"))
):

@sursumCorda Yes, you're right. Thanks for noticing that. So a corrected Matrix constructor is

<
    <x, seq(nprintf("%4.2f", j/100), j= 0..9)>^%T,
    <
        <seq(nprintf("%3.1f", i/10), i= 0..35)> |
        Matrix((36,10), (i,j)-> evalf[4](evalhf((1+erf((10*i+j-11)/100/sqrt(2)))/2)))
    >
>;

I came up with a much simpler explanation of how to derive the equation. It's essentially the same as the above with the steps to compute C removed because it's easy to see that the sum of the distances to the foci is exactly the major-axis length. I also made explicit the steps needed to get rid of the square roots to get the standard polynomial form.

restart:
Dist:= (P,Q)-> sqrt(add((P-Q)^~2)):  #Euclidean distance between points P and Q

P:= <x,y>:                       #An arbitrary symbolic point on the ellipse
F:= [<0,-5>, <5, 0>]:  MA:= 12:  #Givens: Foci and major-axis length

(* An ellipse's defining property: The sum of the distances from any of its
points to its foci is constant. I'll call that constant C for the moment. 

The major axis is the line segment that the ellipse cuts from the line 
through the foci. If we measure the distances from either of the points where
that line meets the ellipse (those points are called vertices) to the foci, then
you can see that C is the length of the major axis. *)

add(map(Dist, F, P)) = MA;
             sqrt(x^2 + (-5 - y)^2) + sqrt((5 - x)^2 + y^2) = 12

expand(%^2);  #Squaring gets both sqrts into a single term
                    2*x^2 + 2*y^2 + 10*y + 50 + 
      2*sqrt(x^2 + y^2 + 10*y + 25)*sqrt(x^2 + y^2 - 10*x + 25) - 10*x = 
                                144

#Separate terms with and without sqrt:
selectremove(hastype, (lhs-rhs)(%), anything^(1/2));
             2*sqrt(x^2 + y^2 + 10*y + 25)*sqrt(x^2 + y^2 - 10*x + 25),
                         2*x^2 + 2*y^2 - 10*x + 10*y - 94

`-`(expand([%]^~2)[]);  #Square both groups, then subtract
                476*x^2 - 200*x*y + 476*y^2 - 2880*x + 2880*y - 6336

(primpart/sign)(%);  #Cancel common integer factors of the coefficients
                  119*x^2 - 50*x*y + 119*y^2 - 720*x + 720*y - 1584

@mmcdara Because of the special evaluation rule of piecewise, decisions is seen as 1 argument rather than 2, just like it is with `if`. So piecewise acts as if it has 2 arguments. When piecewise has an even number of arguments, then a default value is used in case all the conditions are false. Usually, the default value is 0, but it's possible for the user to change it.

@hojat You can skip the derivatives entirely; NLPSolve will compute them in the background if needed. Doing simply

NLPSolve(I1, assume= nonnegative),

I get

[1.53301315530314795*10^(-13), [gh1 = 0.154462739528209, gh2 = 0.371529041174829, gi1 = 1.37108385850808, gi2 = 0.860957036085277, gl1 = 12.9569226548585, gl2 = 9.39082402975947, gs1 = 1.04561251174819, gs2 = 0.586651783990275, p_i0 = 8.48431621548923*10^(-7), p_i1 = 0., p_i2 = 0., ph0 = 2.39549267065501, ph1 = 1.88487638439243*10^(-8), ph2 = -8.56043422781661*10^(-10), pl0 = 0., pl1 = 4.86320524745181*10^(-7), pl2 = 0., ps0 = 0.599755159534200, ps1 = 0., ps2 = 0.]]

I don't know whether nonnegative is a valid solution for you. It's just an example.

@hojat Why "estimate" or approximate the derivatives when you can compute them exactly, as you already have?

@digerdiga I agree with your formula for D(f^k), except that Maple syntax would require ln(f) to be ln@f. 

There seems to be some deeper problem with D applied to any `^` expression whose exponent (2nd operand) is not of type complexcons (explicit complex constant).

@rlopez The effects of bad typography are often subconscious: longer time to read, agitation, irritation, tiredness, eyestrain, reduced comprehension. The reader may not be aware of the cause of these symptoms.

@hojat I think that after changing Gamma to GAMMA, you are not re-executing the code from the restart command. If I execute your modified code, I get 

Error, (in Optimization:-NLPSolve) no improved point could be found

This new error is much different from the prior. It is not due to a simple syntax issue. It is due to a more-fundamental mathematical issue with solving the problem.

Here's a synopsis: Your objective function I1 is a function of 20 variables. Your call to NLPSolve is essentially equivalent to

"minimize I1 subject to gradient of I1 = <0, ..., 0> (vector of 20 zeros)"

with no other constraints. I suspect that type of thing is slightly outside the designed scope of NLPSolve. The more-usual solution technique is

1. Find via numeric solution techniques the values of the 20 variables that make the gradient 0. This step looks only at the gradient, not the objective.
2. Evaluate the objective at the hopefully finite number of points found in 1.
3. Find the minimum of the evaluations from 2.

I'm not saying that this is computationally feasible (given the large number of variables)! My first choice for attempting it would be the freely downloadable 3rd-party package DirectSearch.

@sursumCorda You misunderstand the purpose of RealDomain:-solve. Its purpose is NOT to return all complex solutions that are also real. RealDomain is correct to return only one solution for this problem. 

Good catch. I confirm that these examples also don't work in Maple 2023, even though the help page ?D clearly says that ... assuming x::constant or ... assuming k::constant should work.