How to alternately join rows of two matrices into a single matrix?

Thank you so much!!!

So what would be your recommendation or suggestion?

In the attachment the rule for iteration commands (Sequence, Zip, KeepIf, etc.)

That's very interesting. I am currently struggling to find out what exactly is allowed with lists and what not, especially when it comes to potentially differing types of their elements (which I often don't have full control over).

So you are saying that the rule for iteration commands (and maybe more list commands) is that "all elements of the list must be from the same type as the type of the first element"? Where does that come from? I never read that anywhere in the online manual.

And then there is the question of how that is meant. One could read it as "if a list contains elements of different types, then the use of such a command has an undefined behaviour" (so even it works in some cases, it is not guaranteed and the behaviour might change any time). For your l3 you seem to read this rule more like "on lists with elements of different types, such a command will simply ignore the elements that are of a different type than the first" or - what's more likely - "on lists with elements of different types, such a command will simply (try to) interpret every element as of the same type as the first element", and such commands still have a well-defined behaviour even for "mixed" lists. (This last interpretation might actually match some weird behaviour I have seen.) But is this how it is officially supposed to work, or is it just what seems to happen but is not actually guaranteed. If it's indeed the officially supposed behaviour, then this would allow for plenty of such "tricks" to work properly with mixed lists. (And I don't even mean "really" mixed, but sometimes I have lists where all elements can be properly interpreted as of the same type, but list commands fail because GeoGebra decides to intepret some element the first element differently, because it also fit some other type. Or rather - if this rule is true - GeoGebra interprets the first element differently, and then the other elements can't be interpreted in the same way.)

The way Flatten(l1) works also suggests when something has the type "list" then it's not even that important what kind of elements that list has. Otherwise the the second element of l1 (a list of strings (or text objects)) would be of a different type than the first element (a list of numbers), and then Flatten might have produced something different (depending on what the rule actually is).

Die List-Befehle wurden nicht von Juristen oder Mathematikern programmiert. Und so ganz genau weiss vermutlich niemand wie sie im konkreten Einzelfall funktionieren (das ist überall so, wo etwas programmiert wurde).

Die beste Auskunft über das konkrete Verhalten von ggb erhält man von ggb selbst, indem man entsprechende Experimente, die eine Vermutung bestätigen oder wiederlegen sollen, durchführt. Allerdings: die meisten Anwender interessiert das solange nicht, als sie nicht an irgend einem Punkt anstehen.

Ob meine "Regel" sauber formuliert ist und in allen Situationen richtig und vollständig ist, ist eher unwahrscheinlich. Aber für meine Zwecke hat sie bisher genügt.

Ah okay, dachte ich mir fast. Schade. Für kleinere, private Dinge werde ich das zwar vermutlich auch so handhaben, aber ansonsten bin ich da abgeneigt. Wenn im C++-Standard für das Nutzen einer Routine mit bestimmten Parametern ein "undefined behaviour" angegeben wird, dann darf ich mich als Entwickler auch nicht auf irgendein aus Tests ermitteltes Verhaltensmuster verlassen, denn das hängt einfach von der Implentierung des benutzten Compilers ab und kann sich jederzeit ändern.