[Bug] Sending unicode via XP macro uses a delayed Shift state

[Ceremony64]

Describe the Bug

The XP keycode macro allows for using shift/capslock state to choose between two unicodes, just like a regular alphabet key outputs a lower or upper case character, depending on the current shift/capslock state.
Unfortunately, this is no longer working as intended: The shift state when triggering a XP macro gets delayed once every input. Let me explain with this very simple keyboard layout/config (keymap.c):

#include QMK_KEYBOARD_H

enum unicode_names {
    a,
    A
};

const uint32_t PROGMEM unicode_map[] = {
    [a] = 0x0061, // a
    [A] = 0x0041  // A
};

const uint16_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = {
    [0] = LAYOUT_3(
        KC_LSFT, XP(a,A), KC_B
    )
};

When triggering the XP macro, the state of the last shift state of the previous XP trigger is used for the current one.
Here is the a sequential key press table of what is happening:

KC_LSFT	Key	Output	Expected	⚠
No	XP(a,A)	a	a
Yes	XP(a,A)	a	A	⚠
Yes	XP(a,A)	A	A
No	XP(a,A)	A	a	⚠
No	XP(a,A)	a	a

Also, the shift for the XP macro is saved even when shift has been let go or even when another key has been pressed inbetween:

KC_LSFT	Key	Output	Expected	⚠
No	XP(a,A)	a	a
Yes	XP(a,A)	a	A	⚠
No	KEY_B	b	b
No	XP(a,A)	A	a	⚠
No	XP(a,A)	a	a

System Information

• Keyboard: XD96
  • Revision (if applicable):
• Operating system: Windows 10 2004 & Linux Manjaro (kernel 5.7)
• AVR GCC version: 5.4.0
• ARM GCC version: 7.3.1
• QMK Firmware version: 0.9.19
• Any keyboard related software installed?
  • AutoHotKey
  • Karabiner
  • Other: WinCompose 0.9.4 (on Windows)

Additional Context

Issue occurs on both linux and windows, so its OS agnostic. Also, XP worked for me last time I compiled it, which was a little over a year ago tho, so something must have changed

[jobe451]

Bug also confirmed on Win 10 and Ubuntu 20.04 with handwired/dactyl_manuform

[sigprof]

Looks like this was broken in #8770. Before that change process_unicodemap() invoked unicodemap_index() after unicode_input_start(), and therefore unicodemap_index() needed to get the modifier state from unicode_saved_mods, because unicode_input_start() temporarily resets the modifier state to make Unicode input work properly. After #8770 process_unicodemap() invokes unicodemap_index() before invoking any Unicode input functions, therefore unicodemap_index() now needs to get the modifier state in the usual way (get_mods(), and probably also get_weak_mods() and get_oneshot_mods() to make those things affect the XP() keys properly, which may also fix #9405).

[rupa]

I was able to find and swap out the unicode_saved_mods reference @sigprof kindly pointed out for a call to get_mods() and it did fix this issue for me :)

[spidey3]

With the merging of #11220, this should now be fixed.