@daljit97: See second part of my answer below.

@ecterrab: As I expected, but quite ok. As I said yesterday, I can live with it.

@ecterrab: Thanks four your extensive explanation. I completely agree with you when you write "As a physicist, I thought this behaviour was undesired, prone to mistakes."; as a physicist, too, I thought the very same thing. But as long as A^2 = A . A, consistently, for any square Array, I can easily live with the difference in behaviour between ^ and `.` when applied to Arrays and Matrices, respectively. I will just have to remember that it is defined that way.

PS: Using Maple 2017, can I install version 240 or later of the Physics package? I cannot, can I? If not, it is not that big a deal, for in view of the fact that I never really use elementwise multiplication of Arrays in my work, I will just have to remember to convert 2D Arrays to Matrices before multiplying them or raising them to some powers. I can live with that.

@Pascal4QM: Thanks for your answer. I need not to perform elementwise operations, though. I discovered the 'broken behaviour' because I had this square 2D Array A which I needed to square in the Matrix-sense. As I had loaded the Physics package (for other purposes), A . A gave the same result as the square of the Matrix corresponding to A, and so I was under the illusion that it did not matter in that particular context to be a bit sloppy about Array versus Matrix. But it does matter, as I subsequently found out when preparing my question using a 'clean' worksheet with no Physics package loaded.

PS: Are you using the latest version of Maple?

@Harry Garst: Commands like map and select (and remove) can be very powerful, especially when combined. I vividly recall the revelation it was to me when I first, at this very site, learned about these commands and their application.

@Christopher2222: Thanks.

You certainly have a point. The problem is only present, though, if matrix (lower case) rather than Matrix (upper case) is used; I have just tried it. As I believe the former is deprecated, I took the liberty with OP's code and changed it to the latter, and thus did not become aware of the problem. But, of course, if OP wants to stick with matrix, then your solution is required.

@ecterrab: No sweat, sure I will try again: Now it works, thanks a lot.

PS: Although I don't know what it precisely means, using the LibraryTools:-Browse applet, which I did not know about, the priority of PDEtoolsNormal.mla is found to be 3000017, whereas the priority of Physics2017.mla, say, is 3000016.

@ecterrab: Thanks for the zip-file (and thanks to acer for making it possible). But it still does not work for the Schwarzschild metric, even though I have placed the mla in the same library folder of mine where I successfully put any mla Physics-update.

@ecterrab: Thanks a lot for this 'personal' patch. I am, however, unable to locate the attachment in your post; is it just me being blind, or what?

@ecterrab: Thanks. Unfortunately, and that is not your fault, of course, I guess I am unable to install it as I am running Maple 2017.

@Adam Ledger: See my new suggestion above.

It is a pleasant surprise to me to learn of the addition of such a command to the vocabulary of Maple (I only have Maple 2017, so I was not aware of that addition). For I have always found the use of a break  statement in a loop an ugly thing.

Many years ago, back in high school, I did some programming in COMAL 80 which had such an until-command. But it came paired with a repeat starting clause. Perhaps Maplesoft would consider doing likewise?

@ecterrab: In the future I will try to ask direct questions, although I am afraid that I may occassionally fail to do so. Perhaps I will completely refrain from asking a question if I am afraid that I will end up offending you.

Thanks for putting the 'design-record' straight with your "no, we do not want to go that way", for then I know that I will have to create my own code in order to do what I have in mind.

PS: I have never called for Maple to return unevaluated Christoffel symbols for Minkowski space, and even less for Maple to return nonsensical zero for the Ricci rotations coefficients for Schwarzschild spacetime. I may have my idiosyncracies, but I am not stupid.

@ecterrab: Thanks for that 'recipe'. Perhaps I am ungrateful, but I would have preferred to have these two symbols being given by the system, the symbols being, of course, degenerate for flat spacetime. For one thing, there would then be no need to specify 'galilean' or 'nongalilean' in Setup.

PS: On reading your post it suddenly dawned on me that the capital E used for the nongalilean case is an uppercase epsilon. Earlier today, I could not figure out what that letter/symbol actually was. And there seems to be no mentioning at ?LeviCivita of any such uppercase epsilon; perhaps that should be remedied?

@ecterrab: Thanks for your answer. I don't really know what to make of it, though. As hinted at in the other thread mentioned, I would like to be able to calculate symbolically with vierbeins in having general expressions never being evaluated in terms of some concrete vierbein, but only simplified if possible generally.

The above-mentioned expression for the Ricci rotation coefficients is seemingly maintained generally/unevaluated for the Schwarzschild metric, but evaluated (to zero, quite right, of course) for Minkowski spacetime, even though in both cases the vierbein has been concretely evaluated 'behind the scene' in terms of the metric. Why that difference? A potential argument in terms of different degrees of complexities for the two cases makes little sense to me, I am afraid.