It is a problem I have in my radar and I am working on but I missed one part that I understood while explaining it to @kYc0o

Problem in the implemented solution:

If the problem was indeed a "dependency" (same for i2c_1 and i2c_2), then:

• The dependency must be checked with USEMODULE and not FEATURES_REQUIRED. It could be declared as a FEATURES_OPTIONAL (was also wrong before)
• The dependency to flash_common should indeed be expressed as a FEATURES_REQUIRED because some cpu may not provide it and it should fail.
  • As currently cpu/stm32_common/Makefile.dep is not processed by Makefile.dep it would not be checked
  • In practice, all stm32 providing periph_flashpage or periph_eeprom also provide periph_flash_common so it does not add anything in practice
• The cpu dependencies and features should be parsed by the build system (which is not the case) and depends on many things Build dependencies - processing order issues #9913

But in fact, the part that I missed before, here the selection of flash_common is not a real module dependency or anything.
It is just that the implementation of flashpage.c and eeprom.c use common functions in flash_common.c.
Using periph_ and submodules to include the source file is exposing internals of the module to the outside for nothing.
The real solution is to add things to SRC if the module is there.

I will provide a PR in this direction.

The dependency to flash_common should indeed be expressed as a FEATURES_REQUIRED because some cpu may not provide it and it should fail

Actually flash_common is not really a feature as it exists only on stm32 for internal reasons.

I'll take a look to your PR which seems better :)

Close in favor of #10153