I work on Spectrum, Adobe's design systems team.
>extremely difficult to maintain
Often yes. This corner of the industry is in the wild west days, and we've yet to establish best practices for a lot of things. Most DS teams are writing custom tooling. It helps a lot, but there are growing pains as we figure out which knobs need twisting and how to automate twisting them.
> All design systems I see are art directed.
To a degree. We make a LOT of compromises in the interest of maintainability and using visuals and abstractions that generalize well across platforms. Naming conventions, interaction styles etc are often chosen on the basis of being feasible on many platforms, even though that means foregoing some of the flasher stuff might only be appropriate on, say, iOS. Adobe specifically has a particularly heavy burden here, since we have so many properties spanning platforms from the last 3 decades. We could be a lot more adventurous if we had a smaller device footprint.
Accessibility is another big concern for us. Contrast ratios, text sizes, etc. Lots of the trendy low-contrast design practices don't fly in our system, and that's intentional.
>handcrafted vs generated
In Spectrum's case, the design documentation [1] (guidelines on usage, etc) do have custom content, though it adheres to a template and is inside a CMS that allows both editing by non technical contributors (content strategists, designers) and by script (markdown, etc). We have to strike a balance between optimizing for maintenance (autogen everything) and optimizing for content quality (expressive contribution from people that don't necessarily think of content in terms of automated maintenance).
Much of our "real" content is maintained in much more automated ways. The UI kits, for example, are generated from a JS + SVG lib that consumes our design tokens (variables for properties in the system across themes, platforms, languages, etc).
> is this versioned
Yes. It was an ordeal, but it was important and I'm glad we did it. Components are individually versioned and have a changelog. One of the main things we're versioning is more a snapshot of intent, and less a single specific code asset. Let's say button is version 5.0.0. Other parts of the system, like the CSS and react implementations, are independently versioned and track the design system version. This sounds messier than it is, though it's definitely imperfect.
> what happens if it's updated? How should the changes at this stage propagate down to the individual teams who consume this design system?
we update assets like the guidelines and UI kits on an as-needed basis. Some of this is automated. Some things, like our "don't" examples are created by hand, since definitionally the system doesn't do them. Some changes (bugfixes, implementation refactors, etc) don't require that the design artifacts change.
Our downstream customers (and the team itself) consume our data via a package of design tokens, which are issued as JSON. We update these values in accordance with changes to the guidelines, and those changes propagate to our customers and to our automated tools like the UI kit generator.
> long term sustainability
We're on year 4 or 5 here, and it keeps getting easier as we get better at it. Keeping the design tokens API fairly stable and extending support for previous versions where possible have been big factors in our long term success. While we aim to make update costs as cheap as possible, we also try not to pull the rug out beneath product teams that have slower release cycles and who are bought into previous versions of the system.
Happy to answer other questions.
[1] random docs example: https://spectrum.adobe.com/page/button/