I don't use Mac, so I can't test.
The previous mention however, applies in the same way to all OS, hence it is information I could supply. And it has in the past in similar ways happened on Linux.
Anyway, if you are 100% certain that all other custom controls work (e.g. AtSynEdit / mind that many grids, albeit custom, do use a normal TEdit for input, and therefore their input is actually not custom).
So if you are certain, then it might be a conflict with the configured keys.
In the IDE they are in Tools > Options > Editor > Keymap.
In TSynEdit on your own app, the object inspector will list them as a property "KeyStroke" (IIRC) of the SynEdit.
If any key matches the physical key that triggers the accent, the that key will be used on its own, and never mades it as accent. The key may in the list appear with some generic description (according to VK codes, or some default keymap / I am not sure about how it will be labelled)
Simple clear *all* codes from KeyStrokes and test.
What I'm worried now is about why the IDE is putting the unit of SynEdit but not SynEdit1: TSynEdit; inside TForm
Does that also happen with a brand new project?
- Usually that points to a problem parsing the rest of the code in the unit. Though in that case an error dialog should pop up.
- As for Lazarus 2.3 there was a recent fix (this week) regarding a maybe related issue, where sometimes the projects package list wasn't updated.
Also mind, that fpc 3.3.1 can be unstable at times. At current I know of at least one bug in it, that actually generates wrong asm code for some projects. It shouldn't affect SynEdit, but I don't know about lcl/widgetset.
https://gitlab.com/freepascal.org/fpc/source/-/issues/40165