Bracketed paste interference on Windows

[curlpipe]

Describe the bug
Enabling bracketed paste on alacritty on windows (even though bracketed paste doesn't work on windows #737) causes interference with the pasting of \n characters by adding the control modifier to the Enter key event.

Not using bracketed paste makes pasting work as expected with \n characters showing up as an Enter key press with no modifiers.

Could this just be a weird quirk of how terminals work, or is this a bug? Not entirely sure.

To Reproduce
Steps to reproduce the behavior:

1. Modify the event-poll-read example included with crossterm to enable bracketed paste
2. Run the modified event-poll-read example on alacritty on windows
3. Using the terminal emulator's paste shortcut, paste in some text that contains a newline in it
4. Observe that the newline has a CONTROL modifier

Expected behavior
The key event should be free from the CONTROL modifier, as it is on other terminals, even if bracketed paste is enabled but doesn't work.

Screenshots

In each example I pasted the string a\nb into the terminal using ctrl+shift+v

event-poll-read with bracketed paste enabled:

Notice the CONTROL on the Enter (unexpected behaviour, should be the same as if bracketed paste was not enabled)

normal event-poll-read with no bracketed paste:

No CONTROL on the Enter key (expected behaviour)

OS

• e.g. Windows 11

Terminal/Console

• e.g. alacritty