Consider adopting the core country.default schema

Thanks for opening this issue. But hrm, reasons I don't love this proposal:

1. This module has no global settings. It's "just" a set of render elements and field types. It seems like it'd be a little weird to add a whole configuration form for this one "global" setting.
2. There's already been a lot of trouble and bugs around default countries. 😅 But (I believe) it all works as expected now. If folks want a default country for a given address or country field, they can configure it at the field level.
3. Seems a little wonky how ./src/Element/Country.php is using \Drupal::config('system.date')->get('country.default');. It seems to only happen for Address or ZoneTerritory elements that are required and have no default value. I don't completely follow the need for it at all.

Personally, I'd rather just remove the references to it if core wants to remove this setting entirely, and not try to provide it ourselves. But I'll hand this over to @bojanz for input, since he understands these details better than I do...

+1 to what dww said.

I am fine with not having or using this setting at all. We only introduced it in the 2.0 release ~4 months ago, to have a fallback when the field has no default value configured, and it was community requested.

@bojanz: Thanks for the input! I didn't notice that it was added so recently. I'd be fine with reverting that commit. Then we're no longer referencing this setting at all, and core could go forth and remove it...

@nicxvan / @andypost: Looks like this is "won't fix", at least from our perspective here in address.module land. Do you want to just close this and open other issue(s) in other possible candidate projects? That seems cleaner than moving this one around.

Yeah, as I was thinking about this more, address is a pretty hefty dependency for other modules just to have a default, and most modules use it the way you do, just to set a default on a form the user may override anyway.

Agreed, thanks.