good point I thought native windows support is already dropped within oxid, so if this is a valid usecase then a clever default is also a alternative.
I think customisation should not be done in modules installed by composer, modules should be generic, configurable and easy to update. all other customisation should go in custom theme (e.g. by disabling blocks of that module), in other customisation modules and settings. This will make your project simpler to do upgrades and reduce upgrade costs. Anyway it may help to understand that I am try to reduce custom modules in my project in favour of generic modules that can be shared across multiple projects.
For custom modules I am used to place them inside module source folder directly (and only register them to composer to get the autoloading working, but not for handling updates)