(Please remember to post a worksheet instead of text and screen shots.)

There is no bug. This is the answer to your question, and at the end two suggestions to avoid these subtleties.

From your signature, you are choosing position 1 to be timelike, and 2, 3 and 4 to represent the three spacelike components. With that in mind, take a look at the components of

So the Pauli matrices are ,  and , as you can also see in this output

So what you do expect for the components of  where Psigma is indexed with a space index a?

The above turns on the lights regarding the shifted value of the space index a : the tensor you are indexing,  is a 4-dimensional tensor, and being that the 1st component is timelike (not Physics's default but your choice of signature), the space components are given by shifting the 4-dimensional index by one.

How about a true space tensor? Let's define one of them, another mixed, and one all spacetime for experimentation

For , a space tensor, the components are given by

You see they are not shifted. The index a runs from 1 to 3, not from 1 to 4 such that you are only interested in the components from 2 to 4.

How about the mixed tensor ?

Again OK, and you see: there are 4 lines indexed from 1 to 4, and 3 colums indexed from 1 to 3, because a is a space index. How about , where in  we want only the space part of the spactime index ?

This is again correct, but the 3 columns are indexed from 2 to 4, not from 1 to 3 as in (8) for . I hope it is clear now: when you set a signature with timelike component in position 1, the space part of a spacetime index is given by shifting the value by 1 to skip the timelike component in position 1.

With these things in mind lets give a closer look at your example where you define a covariant derivative operator as . The first problem is that you use the letter D, which is a Maple command representing differentiation. If you proceed as you did, you effectively not have the D command anymore, which is bad. Instead, I suggest you first input

Now you can use D without cancelling the Maple differentiation command D

Check

Let's sum over the repeated index a. In view of the comments lines above, what do we expect? In , the index a is a space index, running from 1 to 3. In , the index a represents the space part of a spacetime index so it runs from 2 to 4. Then

That is the result you are getting when entering and that motivated your question: the index a in  runs from 1 to 3 but the index a in  runs from 2 to 4.

Of course you could have all this in mind, and the computations will run correctly, you don't need to worry. Or the details are not in your mind and get in doubt (your post). I have some suggestions to avoid falling in these subtleties

Compare. These are the current components for your A defined as a mixed components tensor

with these other ones after redefining A with two spacetime indices

I believe the above is what you wanted. So now you have

and you get what you where expecting  for .

This first part is your worksheet:

====================================================
Answer: that simplification only works for the metric. What you see in

is the trace, as in

For   there is no trace, and if you want the sum over repeated indices, you already have that command, as you show in (6). This other example, of a tensor with two indices, may help see the difference

Also

But not

The case of the metric is indeed special. In computations with paper and pencil in Physics, we (more often than otherwise) want the trace to be explicitly computed, but not for all other tensors. For them  does the job and with several options (check its help page). And what if you want the trace of the metric to not be computed? Use the inert form

This is your ODE and dsolve's solution, all tests OK

dsolve's solution computing the integral also tests OK

dsolve's solution in explicit form requires  and also tests OK

Now, this is your solution, ,

I don't know from where you got this expression, but to my eyes it is not a solution to ODE. Remove the  to test the actual expression behind

Regarding testing your expression (not a solution) explicitly as if it were a solution, you hit a bug, but not in ; it is in , this is the expression, resulting from your not-a-solution, that goes into an infinite loop within

radnormal(ee);