Key signature added in measure that was previous at start of system does not appear

I can't reproduce this using the Beta build, not with your attached score or one created from scratch. With your score, I tried doing what it appears your picture shows - adding G major to measure 12 - and it worked as expected. This was true whether I used drag & drop or double-click. However, there are certainly some other weird things going on with key signatures especially in imported scores that can be dependent on the order in which you do things, and of course I don't your picture, so clearly, there is a bug here. We just need to understand better how to reproduce it.

My money is on all of this being related to #279034: Generated key signature and clefs not removed

I was able to reproduce the problem in part. Here is exactly what I did:

Create a score using Classical Orchestra template (the one with the staves visible)
Switch to transposed pitch view
Insert E-flat time signature
Enter 2 8th note F's on first beat of score.
Select measure and press R until 3 measures on second system have notes (this is a total of 11 measures on my system).
Insert G key signature in measure 5 - This looks normal
Insert E-flat key signature into measure 10.

Several bad things happen at this point:
The key signature in measure 10 is not shown - but the F's are marked as natural
The invisible key signature cannot be undone. - undo once (to get rid of the invisible key signature.
The F's in measures 10-11 are still natural.
Enter an E into measure 12. It's reported as E-flat
Enter a key like A into measure 11. - It's invisible and the E in m. 12 gets its needed flat accidental

Save and reopening the score seems to fix it at first glance.

I got slightly different results if I entered notes into measure 11 before I undid the G key signature. So that affects it in some way.

Confirmed. I can also reproduce from other templates, but not from all of them. Guessing at this point that transposition plays a role in this.

I can't reproduce from scratch, but I was working on a string quartet, that uses no transposition. Adding a global time signature (selecting violin 1) led to this bug. Saving and reopening the score cleared the issue. The Key signature was not included when reopened and the accidentals were inserted on the proper notes. This is a slightly different effect than previously reported, but seems it will be related.

The problem is that I was just working and it happened. When I tried to reproduce the problem it didn't happen. My string quartet is working fine now.

I am looking at this. Following the steps from https://musescore.org/en/node/279096#comment-872848, I notice that after inserting the G major key signature in bar 5 but before inserting the Eb in bar 10, there is an existing "disabled" key signature segment there. Supposedly that's OK. I'm told it's because we are saving information about the key signature that used to be there. There are actually quite a few measures with these, I guess because as you add notes at the beginning of the score, a different measure gets to be the first measure of the second system.

Anyhow, what happens when we insert the Eb in bar 10 is that it too becomes "disabled". Same if I drop onto any of the other measures with disabled key signature segments.

If I'm right in this analysis, the fix is simply to be sure to re-enable the key signature segment upon dropping a key signature there.

This management of enabled/disable key signature segments is something we'll have to be careful about to avoid more bugs like this! See also #279609: Inserting measure before measure previously at start of system displays spurious key signature which also results from incorrect management of disabled segments. And now it occurs to me #279183: Adding time signature to measure with clef changes produces notes on wrong lines could possibly also be example of this.

Enabling key signature segment on manual addition of a key signature will make it displayed but then we have to manage it somehow to make it undoable. Another issue is that undoing of adding a key signature to such a segment will cause an extra key signature event to appear (as it is done in this case via ChangeKeySig undo entry) which will cause unexpected effects on trying to change key signature somewhere before that measure. Maybe these problems can be circumvented but they definitely need some attention when fixing the discussed issue.

As an option, maybe the solution could be to abandon the concept of enabled/disabled segments at all and handle reusing measure header/trailer separately (if that is needed)? It seems disabling segments has currently no other purpose, and the presence of such segments in the common segments list creates a lot of difficulties in handling them.

I agree this might make sense, but it looks to me like it is in there pretty deep at this point. I think it would be a big & risky job to remove this. My sense is we're better off continuing to patch the problems as they are discovered for now, maybe revisit this after release.

Anyhow, here's a PR: https://github.com/musescore/MuseScore/pull/4353

BTW, workaround is to save then reload the score.

Another interest aspect of this:

1) new score
2) line brek after measure 4
3) add C# major signature to measure 1
4) add C major key signature to measure 5 (beginning of second system)

Result: way too much space at first - there is room being left for the key signature that is no longer needed

5) add a note to measure 5

Result: space goes away, which is good

6) Undo all the way back to the beginning

Result: a C# major key signature remains at the start of the second and each subsequent system thereafter. Furthermore, if you enter C's starting at the beginning of the score, at measure 5 they start sounding and acting like C#'s.

Fixed in branch master, commit e73421ac37

fix #279096: fix changing key for initally generated key signatures

Automatically closed -- issue fixed for 2 weeks with no activity.