Greetings!
The failover behavior you described is as intended — when a failover occurs, the standby becomes the new commander and retains that role, even after the old commander reboots and rejoins the stack. This is done to minimize unnecessary reboot cycles, as rebooting a stack member takes down all ports on that member until the reboot is complete. The priority setting comes into play when a stack election occurs, as happens if both the commander and standby (or an entire stack) has rebooted at the same time; it will not cause the standby to relinquish the commander role when the original commander rejoins.
Keep in mind that there is little practical difference in stack operation with the standby operating as the commander — it retains the same configuration, and as long as all stack members are operational, it behaves identically no matter which member is operating in that role. (One of the only operational differences can be observed when connecting to a non-commander stack member via serial console — the serial console redirect function causes the session to operate with a set console height and width, ignoring the settings used by the terminal application being used.)
With regards to the second question — depending on the switch model, either the switch status LED (for 2930F/5400R VSF stacks) or the stacking status LED (for 3810/2930M backplane stacks) are expected to flash to indicate that there is a stacking-related issue — either a link is down, or one or more stack members are missing. The LEDs should return to normal once the issue has been resolved; if you are not seeing this behavior, please post sanitized event logs and the results of show stacking or show vsf so we can determine if this is a bug.