🔵 Describe the bug:
Natures swiftness will only cast as a macro on GSE if it's the only block in the sequence (based on what I can tell) and blocks the shift modifier from working in any block

If the only block is:

/target [@mouseOver,noharm][@TARGETTARGET,noharm]
/stopmacro [channeling]
/castsequence [help,mod:shift,nochanneling] reset=3/target Nature's Swiftness, Regrowth, null; [help,nochanneling] Regrowth

OR

/castsequence [help,mod:shift,nochanneling] reset=3/target Nature's Swiftness, Regrowth, null; [help,nochanneling] Regrowth

OR

test (THIS IS THE NAME OF THE MACRO THAT WORKS FROM /MACRO WHICH IS A COPY OF THE FIRST BLOCK LISTED)

Then the sequence works copletely

If any other blocks are added to any of these other blocks, the ability to use shift for nature's swiftness fails. As does ANY OTHER SHIFT modifier in the sequence.

Here's the entire block that fails using shift modifier

{
[1] = {
["macro"] = "test",
["type"] = "macro"
},
[2] = {
["macrotext"] = [[
/target [@mouseOver,noharm][@TARGETTARGET,noharm]
/stopmacro [channeling][nocombat]
/cast [@Focus,help][@player] Ironbark
/cast Convoke the Spirits
]],
["type"] = "macro"
},
[3] = {
["macrotext"] = [[
/target [@mouseOver,noharm][@TARGETTARGET,noharm]
/cast [@player,mod:shift] Innervate; [nochanneling,combat] Swiftmend
]],
["type"] = "macro"
}
}

Notice that the mod shift Innervate in the 3rd block isn't special, but it doesn't work either.

I duplicated to a different sequence in order to see if the sequence was corrupted somehow, and it looks like this

{
[1] = {
["macrotext"] = [[
/target [@mouseOver,noharm][@TARGETTARGET,noharm]
/stopmacro [channeling]
/castsequence [help,mod:shift,nochanneling] reset=3/target Nature's Swiftness, Regrowth, null; [help,nochanneling] Regrowth
]],
["type"] = "macro"
},
[2] = {
["macrotext"] = [[
/target [@mouseOver,noharm][@TARGETTARGET,noharm]
/stopmacro [channeling][nocombat]
/cast [@Focus,help][@player] Ironbark
/cast Convoke the Spirits
]],
["type"] = "macro"
},
[3] = {
["macrotext"] = [[
/target [@mouseOver,noharm][@TARGETTARGET,noharm]
/cast [mod:shift] Innervate; [nochanneling,combat] Swiftmend
]],
["type"] = "macro"
}
}

This also doesn't work with SHIFT modifier. Nature's swiftness, nor Innervate ever fire even though they are in completely different blocks. It also doesn't matter if the block containing Nature's Swiftness is disabled, the entire sequence still is borked.

🔵 To reproduce: (Steps to reproduce the behavior)
See video

🔵 The error:
n/a

🔵 Screenshots:
There's a google drive link of a video showing this behaviour. After the video, I made the separate sequence to ensure it wasn't just that sequences issue, and with a new sequence it still has the same behavour.

🔵 Expected behavior:
Macro works as it would in /macro

🔵 GSE.lua file:
Please provide your GSE.lua file or the export string for the specific macro that is causing an issue.

To find the GSE.lua file:
First, make sure you have enabled the "File Name Extensions" checkbox in Explorer (View tab)
Browse to C:\path\to\wow_retail_\WTF\Account\YourAccountName\SavedVariables\ or /path/to/WoW/retail/WTF/Account/YourAccountName/SavedVariables
Copy the GSE.lua file to your Desktop
Rename this copy to GSA.lua.txt
Then just drag it here in your message
Note: If you do not include your GSE.lua file you are wasting your time and mine. 90% of the time, the first thing I will ask for is "Can you please upload your GSE.lua file?". This file is needed with the error to work out Why that error occured for you.

New updated GSE.lue from today's testing

GSE.lua.txt

🔵 Desktop (please complete the following information):

OS: Windows 11 64bit
Game Version Retail 11.1.5.61265
🔵 GSE Version:

Version: 3.2.31
Downloaded From: curseforge

Google drive link of a video of this happening
https://drive.google.com/file/d/1h9BiVfWAhyImksIQhHPa1a3YftmoH9dQ/view?usp=drive_link

You have a conflict with an in-game shift keybind I'm guessing - open options and search shift - clear any keybind that is a conflict/combination of shift+yourspamkey

I can tell you right now though this IS NOT a GSE Addon BUG - its a user issue.

I use shift+= on other characters with other sequences and it works. I've checked all my bindings. I'll run another test to verify that it's not bindings

Is there any way to clear out a specific keybind? There are no binds for shift + =, nor = (other than GSE), nor are there any hotkeys in windows for that chord, but if I move the same sequence to something like F12, the entire thing works. Is it possible to have a binding that doesn't show in options/keybinds?

So when I went to bind Shift +=, something unbound, see image. This is the binding for my shadow priest? How would that transfer over like that? That binding didn't show on the list of bindings in GSE for any other characters/specs, but was somehow still bound to shift + = across characters?

So that is likely a bug in GSE somehow then right? I'm decent at checking things like that before hand, but this wasn't a visible thing to catch. Is there any way to add indications in GSE that things are double bound, or binds are removed?

Again these are wow limitations that GSE has no control over.

Wow doesn’t have a concept of spec level keybinds. It has character and account. GSE asks WoW to use character level binds however sometimes WoW just does account binds because something happened somewhere else in the your UI (read could be done by the wow keybinding page, any mod or WeakAura) and it just writes all your current keybinds as account level. This action isn’t something that GSE has any control of.

These keybinds have an order that these are processed. OS (Mac /Windows) -> Mod level (SetOverideBinding) (use by GSE in MoP) -> WoW Keybinds +Mod Keybinds (SetBinding) ( this is where your actionbars and GSE operate) -> macro conditionals (mod:xxxx commands) once it tries to hit something on that path it stops it getting to macro conditionals irrespective of it that thing exists or not.

The issue is you have a bind setup on one char and that key combination is then cached by WoW. It’s no longer GSE doing that routing for your other characters. GSE doesn’t even know that binding exists when you are not on the character for which that was set. WoW just picks it up at that point from the cache and re applies it. This is a fundamental limitation of WoWs entire keybinding system that GSE works around when you login by setting the binds you have specified for each character. (GSE can’t even list its keybinds in the Wow keybinding interface because you want to bind to a sequence. The sequence is a wow button under the covers. Because the button name is dynamic (the sequence name) and not “GSEButton1” (nor does GSE even know how many buttons to make initially). You also can’t add an extra button after you have logged in.)

You have two options. Either always use the same keybinds on all characters. So if you bind shift and x on one char you need to ensure you bind shift and x on all characters if you need to use that mod. Option two is to use Actionbar Overrides where your keybinds remain on your actionbars and operate fully within WoW’s keybinding interface. This has the advantage that if you uninstalled GSE or deleted the sequence and Actionbar override there is no impact on any this char or any other characters keybinds. The keybind was never moved from where you had set it in WoWs keybinding. Unfortunately while Actionbar overrides work better for this case they also have their own limitations which you would need to consider. Details for this are in the Wiki

So that is likely a bug in GSE somehow then right?

The TLDR: No its a wow limitation and GSE is doing what it can within it.