It looks good, but I worry about users who will be tempted to make changes like:
analyser_slits.size.set(300)
in their terminal, then because you have only one directional syncing in EntranceSlitInformationDevice layer this soft signal will fall back to Epics value.
Maybe those soft signals should not be exposed at all?

These signals are read only. The write signals are all private. From blueapi side, I believe it doesn't expose private signals. They can only change it via epics (which is how it should be done). The read only config sigs are then given to the detector to record the data at the start of the scan whenever data collection is done. It is also impossible (very hard to do) to sync in the opposite direction as the valid combinations are defined by the epics enums.

why allow here any arbitrary config signals, is there a use case for it or is it not a final class?

This is reflecting how StandardDetector adds config_sigs https://github.com/bluesky/ophyd-async/blob/main/src/ophyd_async/core/_detector.py#L421C2-L421C3

and AreaDetector API https://github.com/bluesky/ophyd-async/blob/1e07267fb12ff511b248a77a5ed5b6ac50364ad9/src/ophyd_async/epics/adcore/_detector.py#L17

The electron analyser detectors currently use StandardDetector, but I am going to move to use AreaDetector soon. I was waiting for stable release of ophyd-async first to make it easier so was waiting for this to be merged first bluesky/ophyd-async#1268

OK, but I mean you could specify here analyser_slit as input parameter and pass down all it's soft signals to

config_sigs = (
            analyser_slit.direction,
            analyser_slit.setting,
            analyser_slit.size,
            analyser_slit.shape,
            self.driver.region_name,
            self.driver.energy_mode,

I could, but then it makes it less generic when I can reuse what it already does rather than adding it to the constructor to do the exact same thing