[sciurius]

If MSPro thinks the song is in Am (which is enharmonic with C), it will produce the A#. So if you have a song in C that happens to start with Am, MSPro will assume it's in Am and surprise you.

Actually, I'm afraid the whole key support of MSPro may need rethinking.

First, what does it actually mean?
In the song edit (properties) form, a song can be assigned multiple keys. What does that mean? I don't know.
A chordpro file can have multiple occurrences of {key: XX}. This can be unambiguously interpreted as: the given key applies from here, e.g. a song with a modulation.
When a song is imported, only the last occurrence of {key: XX} is registered in the song properties. When I explicitly specify a key during import, the (last) {key: XX} is added.
In the Text Display Settings, only one key (the last or only {key}) is taken into account. I assume it will use the key specified during import if no {key}s are present in the file. In most cases, the key as displayed here is ambiguous and serves no purpose (read on).

As it comes to transposition the situation becomes even more complex.
I think we can agree that transposition applies to the whole song. So there's only one transposition.
When thinking in terms of semitones it is relatively easy: all chords are transposed the desired number of semitones. However, this leads to ambiguous situations: Should A+1 become A# or Bes?
It is also possible to define a transposition in terms of a source key and a target key. This solves some abiguities (e.g., when transposed to the key of F an A+1 becomes Bes, not A#) but not all of them. As Mike already noticed, when transposing to the key of C, should A+1 become A# or Bes?
Also, when a song has multiple keys, transposing by key becomes confusing.

Are there any better alternatives? I think so, but that would require an overhaul of the current handling of keys and transpositions.

First, the key property of a song becomes for administrative purposes only. It is the collection of keys specified during import plus all {key:XX} that are in the file (if selected in the config). It can be used for sorting and grouping.

In the Text Display Settings, remove the Key part, *or* change it to "Original key(s): " for display purposes only.

Instead of the Transpose slider and its setting in the config, make a button [TRANSPOSE]. This will call a dialog where the user can choose between steps transposition (+/- 11 semitones) and key transposition.
For steps transposition, use sharps when transposing up, and flats when transposing down. This is a well-established convention.
For key transposition, the user must choose a starting key and a target key (no defaults, no minors!). This can then be interpreted as steps transposition. If the target key has sharps, use upward steps. Otherwise, use downward steps. If the target key is C, we still have a problem, though.

I think this may clean up most of the current key/transposition issues.