Date().toDateString()

Mon 2020.03.02

While not actively involved/engaged with Bangle and this thread as I have only been observing from a distance, Thank You @MaBe for the effort fleshing out the locales object.

'Would be great if this is checked be native speakers'

Wasn't sure if suggestions were meant to be listed here, sent as a PM, or posted at GitHub, So, as the question is asked here . . . .

Not sure if this was just a typo, as it mimics the GB example, for USA we typically use only 'km' for kilometer adopting your Deutsche 'de_DE' or International format:

"en_US"
distance: { 0: "mi", 1: "kmi" },
   change to
distance: { 0: "mi", 1: "km" },

Q: Is the default, element 0 or element 1  ?

If the speed designator is considered the parent, then the distance element 0 would be correct if the answer to the question above is true. Is the display of the speed designator dependent on the default distance label?

Reference

"en_US"
speed: "mph",
distance: { 0: "mi", 1: "kmi" },

I also had an observation with some of the case labels.

Wasn't sure of the specific reference used, so grabbed the first Google response:

https://github.com/abritinthebay/datejs/wiki/Format-Specifiers

Have always had a struggle with 'M' and 'm' as hh:mm:ss looks okay, but MM-dd-yy just doesn't feel right. I'm sure there was some frustration on your end also.

This might be considered a personal preference, but maybe there was a programming reason to use upper case?: (also note the 'M' and 'm' conflict here also)

"en_US"
timePattern: { 0: "HH:MM:SS ", 1: "HH:MM" },
   my preference
timePattern: { 0: "hh:mm:ss ", 1: "hh:mm" },

This one is a little tougher, my preference is for a 'yy' format, but banks, C.C. companies and our Government insist on 'yyyy' So, there isn't an easy way to incorporate both, just yet.

"en_US"
datePattern: { 0: "", 1: "M/d/yy" },
   visually intuitive
datePattern: { 0: "", 1: "mm/dd/yy" },

EDIT: Who is the controlling body for these locales? There are some items there that are not common here in the mid-west, specifically the date format as above:
https://lh.2xlibre.net/locale/en_US/glibc/
http://docs.translatehouse.org/projects/localization-guide/en/latest/guide/locales/glibc.html

Would be interesting to get feedback from other areas of the USA - a few known

West Coast @allObjects
MidWest @Robin
East Coast @DrAzzy
South @DamianMontero

If 'M' is required for the Month to avoid the 'minute' time conflict, then we'll have to accept:

"en_US"
datePattern: { 0: "", 1: "M/d/yy" },
   change to
datePattern: { 0: "", 1: "MM/dd/yyyy" },
   or my preference, both preferred however
datePattern: { 0: "", 1: "MM/dd/yy" },

Tougher yet, as I'm sure this is the desire to have an all three alpha character solution, but for the month of September, Sept is more frequently used:

"en_US"
abmonth: "Jan,Feb,Mar,Apr,May,Jun,Jul,Aug,Sep,Oct,Nov,Dec",
   may a four character month be allowed?
abmonth: "Jan,Feb,Mar,Apr,May,Jun,Jul,Aug,Sept,Oct,Nov,Dec",

Finally, either Thu or Thr of these are commonly acceptable, although I prefer 'Thr' to avoid the 'u' in 'Thu' being confused with 'Tue':

"en_US"
abday: "Sun,Mon,Tue,Wed,Thu,Fri,Sat",
   either
abday: "Sun,Mon,Tue,Wed,Thr,Fri,Sat",

The rest of the 'en_US' locale looks   ok, Ok, okay, Okay !!    ;-)