[DTownSMR]

It fits perfectly for my needs how MSP implements that, no workaround at all.

Different strokes...I'm glad that for you, how it works...umm...works. In my use case it really doesn't and the proposed "solutions" in this thread are work arounds to a fundamental problem that I realize isn't a problem for everyone but it still is for me. Hence why I was pretty specific in my last post...
     "but in the end they are really just workarounds to a specific problem...at least in my use of MSP"

AFAIK, making a copy of the song just for the key change would have me back at the same problem I was running into with PDF's that led me down the chordPro path. Song bloat in my song list and different overlays per key requiring duplication of effort (not to mention being error prone) keeping things up-to-date. Yes, I get it that different overlays is PERFECT for some and is exactly what they need...but again, not in my use case. I need the same annotation overlay in every key and they must be kept in sync. Perhaps there are features I'm unaware of.

As for my suggestion of adding song keys to setlist meta data, I don't see where your use case would be impacted by adding support of key changes to songs in a setlist. You wouldn't have to put the key in for each setlist it would simply use the song metadata key (re: default) for the song as you already set as desired. So you could still do things as you do today (i.e. key changes to a song on the songs tab would be kept as song metadata). But if the a user sets the key in the setlist (re: from within a setlist) the setlist metadata could simply override the song metadata. Seems pretty straightforward to me and gives folks options for different work flows.