IMO, this is a complex choice and depends on the use-case.

As you said, having all units of a building will flood the result, especially when your use case is the address only.

In the other hands... When you need the unit... 🤷‍♂️

I suppose, for the forward geocoding, when you are looking for the unit, all units should be displayed.

And for the reverse... 🤷‍♂️ maybe a meta category address:unit or dedicated query parameter ? But it may be a pain for the integration...

I've demoted this PR from "ready-to-merge" to "draft".

This was originally written to resolve an issue one of our clients was having, they have since solved the issue themselves by performing deduplication of the data before importing it.

As noted by @Joxit, each deployment may wish to configure this differently, so we'd probably need to put it behind a config flag before merging it (if we decide to do so).

@rowanwins, I would be fine with reopening this PR and pursuing getting it merged if you find it useful.

Since it's a dramatic change for existing users we would have to put it behind a feature flag which defaulted to being off.
That means it wouldn't be available on geocode.earth for instance, but would allow developers such as yourself to continue working on unit number functionality in their local environment/own deployments.

If at a later date we could show that this change doesn't make results super noisy then we could make a subsequent PR which changes that feature flag to be on by default, pending a plus one from the core contributors, which would make it available by default on all installations.