Optional property 'erase-block-size' is used to describe the minimum size of flash sector on which an erase operation could be applied. It is generated as a device tree generic define DT_FLASH_ERASE_BLOCK_SIZE (made generic through the use of chosen 'zephyr,flash').
It is optional since, on some parts (stm32f4, for instance), flash layout is made of several sectors of variable size and hence it cannot be provided.
So here is the issue since, on one side, we have a zephyr generic define, and on the other side, we have parts on which it does not exist. Problem is that it could happen that people use it in generic zephyr components, while it is not a generic property (cf last example: ).
Another issue with this define is that it appears to be simple and handy to use, but it is actually misleading since it is only available on embedded flash. So any flash based application, if trying to use it will fail on external flash.
Flash API actually provides an alternate, robust and generic 'flash_area_get_sectors' that will provide the same information with few more computations. And this is the solution to be used.
Unfortunately, there is no automatic way to prevent people using misleading DT_FLASH_ERASE_BLOCK_SIZE.
So the question I'm raising to you is how to avoid facing this issue every 3 months.
Once idea would be to remove it, but it is actually used in device specific embedded flash drivers where it does make sense.
If you're interested, don't hesitate to answer this mail, comment in related issue  or join dev_meeting next week.