Incorrect CSS produced when using custom variants with multiple &'s

[Jason Smith]

I am attempting to add a custom variant to our twin config. In the 2.x branch we were actually patching twin to add support for this, but now that 3.x supports plugins we are hoping to move to the officially supported happy path. The variant we are adding is the following:

addVariant('gp-sm', ['.gp-sm &:not(.responsive-blocker &)', '.responsive-blocker .gp-sm &']);

I've also tried expressing it thusly:

addVariant('gp-sm', [
                ({ modifySelectors }) => {
                    modifySelectors(({ className }) => `.gp-sm &:not(.responsive-blocker &)`)
                },
                ({ modifySelectors }) => {
                    modifySelectors(({ className }) => `.responsive-blocker .gp-sm &`)
                }
            ]);

This produces invalid results for the second & in the first selector. You can see in the tailwind playground the correct selectors are produced: https://play.tailwindcss.com/zqDJvNIcDK?file=config

However when twin attempts to produce the selectors, you get something like

.gp-sm .my-class-name:not(.responsive-blocker .gp-sm:grid-cols-2)

grid-cols-2 is the tailwind class I was applying, but it has been improperly substituted for my-class-name.

[Jason Smith]

For some reason addVariant('gp-sm', ['.gp-sm &:not(.responsive-blocker \\&)', '.responsive-blocker .gp-sm &']); appears to work fine. I dont know why I need to double escape any ampersand after the first one.

[Ben Rogerson]

Tailwindcss versions prior to tailwindcss@3.2.5 produced the output you were after.
I'm unsure why the functionality was changed but I can see there was a bit of work done with variants in the changelog.

[Jason Smith]

Should I chase this down with them? 3.2.6 seems to also produce the correct output on the play.tailwindcss.com website which is why Im a bit confused.