Repeats and Codas act weird when you try to nest them

Your first example says DS al coda, but there is no doa, so no surprise MuseScore gets confused. Generally, any error in the repeat structure will cause unpredictable results.

Second one has the Coda within the repeat, which also doesn't really make sense. I think maybe I can guess what you are trying to do, but it's not really clear to me as an experienced musician, so again, not surprising MuseScore might not be able to guess your intent here either. It kind of looks like something that would be more easily represented with voltas, though.

Third one makes no sense at all - two different segnos and two differen DS's in the same spots with the same labels? But, not weird that repeats are ignored on the DS, that's standard. if you wish to tell musicians to take repeats on a DS, you should write that in explicitly, and if you want to tell MuseScore to do so, you should check the corresponding box in the Inspector.

Basically, nested repeats are fine for C++, but they don't really work well for music except for that specific case - repeats within a DS< if you explicitly tell musicians and MuseScore that you want this.

They act "weird" because they're not really meant to be used as a nesting mechanism. Marc already explained some of it, but I'll try to address your examples by explaining the rationale as to why they behave as they do currently.

Ex 1. The behavior here is entirely Correct and expected; it is a rule in standard notation that a Jump instruction is only followed when the final of the normal repeats for that measure (or volta covering it) is reached.
Another rule is that a jump should result in jumping into either the first normal repeat (when "play repeats" is enabled) or (the common case by convention) into the last normal repeat of the target.
While it is not unthinkable that we expand on the Jump possibilities, it requires some care to ensure we don't break the expected standard notation interpretation of them in addition to a lot more "logical roadmap tracking" for processing those possibilities.
And while we're on the subject, a Jump by convention also does not increase the repeat/playback count (which results in some volta combination oddities); a thing that should also be reconsidered and designed around when allowing multiple jump execution.

Ex 2. Again this behaves as expected in accordance with standard notation interpretation rules. Due to the Coda being inside the repeated section, one could arguably make a case for expecting that the repeat should be retaken three times, as the coda itself should consider resetting the repeat count as well.

Ex 3. You might've gotten a bit more understanding from the previous responses, but here again there is nothing actually weird going on (playbackwise).
What is a bit weird is that you've used a "D.S. al Coda" instead of just a plain "D.S." since you've skipped the "to coda" part of the instruction anyway. You also only need a single Segno marking/label at the beginning; MuseScore only uses the last of them and never even finds the first segno when processing that score.
To re-iterate the rules you're encountering here:
* A Jump instruction is only executed once normal repeats have been exhausted
* By convention, after a Jump only the "final/last" repeat/version of the score is played (this is why the normal repeat bars are "ignored" after the jump). If instead one should jump to the first normal repeat, then an explicit instruction is expected (f.e. change the jump to read "D.S. con rep." and check the "with repeats" option in the inspector for MuseScore to pick up on that instruction).
* A Jump instruction is only executed once (which is why you need both jumps there). I hope to address this in a future release, but no promises as to when.. You can of course here as well edit the text of one of them to indicate it should be followed twice, then mark the other one invisible.
As a sidenote: the order in which the jumps are followed if they are set on the same measure as in this example is arbitrary and not guaranteed.

Ex 4. Nested repeats don't exist in standard notation. An end-repeat barline always sends you back to the most recently encountered start repeat barline. While the reason for this might seem not so clear in your example, it is exactly this convention that makes the alternative endings known as voltas work.
However, for small nestings such as in the example, there are some tricks one can employ; see https://musescore.com/user/2605606/scores/6742244 for an example score.

Ex 5. As for the ignoring of the first repeat barline (fun fact: the start of the score by convention already acts as such; there isn't really a need to insert a start repeat barline at the start of a score) see the reply to Ex 4.
So this again, to me; plays back entirely according to the rules of standard notation.
Re "score can end prematurely": Yes, a volta can have that "effect", if there is nothing to play on a certain repeat, then there is nothing left to do. You can even test this without repeats at all. Just add a 2nd volta over some measures in a no-repeat score and they'll be skipped as well.

test_full
If your intent was to just have a single file with each example one after the other, then you're missing section breaks in-between them. On the thing about Jumps is that convention also requires them to work within a movement/section by default. Only if a referenced marker can not be found inside the current section should one look into other sections.
Since you didn't put those in, you'll notice already that the Jump from Ex 2 is not taken, as we're still looking for the "coda" of the first example, which is found here and thus forwards over to the coda, in doing so skipping over the jump of Ex 2...

--- RE: preferred behavior ---
Ex 1 & 2: As explained in the separate responses, having the Jump being executed on every repeat would break 2 (3 if you're pedantic) of the standard notation rules for them.
While I don't exclude us ever making such an interpretation a possibility in the future, it's highly unlikely to ever become the default interpretation in MuseScore because its simply not how notation works.

Ex 3. I believe I've touched on all of these points above. I'll only add that yes, using D.S. to repeat an entire song isn't very common; however using a D.C. is. It is used mostly in choral works where you have verses or a chorus that already has a repeat; then at the end of a score there is just a simple D.C. indication. The expectancy is for that D.C. to be executed "con. rep" and multiple times, even though nothing for the D.C. command itself indicates this. The lyrics for the song are expected to make that effect clear then.
To my knowledge, this is the only situation in classic standard notation where a Jump is honored multiple times. In MuseScore one can fake this by adding it multiple times and hide all but one of them.

Ex 4 & 5. I find it interesting that you'd see the voltas of 5 being a clearer indication of nesting than 4. To me, it had the exact opposite effect. When a volta is encountered, "it is known" that these are all alternative endings to the preceding start repeat, making it less clear that nesting is going on.
If you do ever want to go for nesting, I strongly suggest the use of non-standard repeat barlines (such as in the linked example) to make it clear which pairs of barlines are linked together. I'd also use this only for very short nestings, where both the inner and outer repeat can be spotted in the same page, or preferably system even.

.
If you're interested in some standard examples that drive this logic, have a look at the automated test suite of scores we use for this in MuseScore; available at https://github.com/musescore/MuseScore/tree/3.x/mtest/libmscore/repeat

So again, I think we will at some point in the future evolve the possibilities of Jumps and Repeats above and beyond default standard notation capabilities (in some areas, we already do); but it requires some thought to be put both into keeping the default interpretation in accordance with standard notation as well as into how to provide an understandable and usable UX around the multitude of complexities in roadmaps those additional capabilities open up.