feature request: "default" key for objects in scales

[folz]

Is your feature request related to a problem? Please describe.
We're overhauling our colors. Formerly we had things like colors.green, colors.darkGreen, colors.lightGreen. We now would like to use a format like colors.green.dark or colors.green.500.

The issue is maintaining a backwards-compatible map of former colors to current colors. As-is, we can't have

// colors
green: {
  dark: ...,
  core: ...,
  light: ...,
}

because colors.green is an object in the new world, but before colors.green resolved to a color value. In order to ship this new theme, we would need to update every callsite that used a color-theme-aware sx rule to use colors.green.core.

Describe the solution you'd like
I would like to set a "default" value for objects, such that colors.green resolves to colors.green.default if colors.green is an object value and there is no subsequent .$key accessor.

Describe alternatives you've considered
We could work around this by using colors.greens (plural), avoiding the namespace collision. I dislike this because we would still have to maintain a colors.green that matches colors.greens.default by hand in order to change existing usages of colors.green. I also dislike this on aesthetic grounds (I just would prefer not having plurals in the namespace)

Additional context
Open to discussion on implementation particulars, I just wanted to get your thoughts on whether this sort of backwards-compatibility support is something you think belongs in theme-ui or should be the responsibility of consuming libraries.

[jxnblk]

Thanks! I like this idea a lot, and it seems like something we could try to put on the v1 roadmap -- I'd imagine the implementation would be fairly small, adding an additional check in the getter function's fallback, but haven't looked into it at all yet

[folz]

Yeah, a getter check is what I was thinking as well. I can work on a PR with the changes for discussion. How do you want to approach putting this on the roadmap, if at all?

[jxnblk]

Feel free to start on a PR -- if it's fairly simple to put together, we can slot it in for v1 later or 0.4 sooner. I suspect this should be a breaking change, even if it only affects a small edge case. If it ends up being complicated or time-consuming, we can also hold off on it