Mapping complex design systems to tailwind utilities broken in v4 CSS config DSL

[non25]

What version of Tailwind CSS are you using?

v4.1.12

What build tool (or framework if it abstracts the build tool) are you using?

For example: postcss: v8.5.6, postcss-loader v8.1.1

What version of Node.js are you using?

v22.19.0

What browser are you using?

Firefox v142.0.1, Chromium v139.0.7258.154

What operating system are you using?

Arch Linux

https://gist.github.com/non25/6e1ddd3d4667aac9c4511d1be7db38ba

Describe your issue

Since the introduction of the new CSS DSL configuration syntax in Tailwind v4, I've found it extremely difficult—if not impossible—to maintain a mapping between a complex, domain/purpose-focused design system and Tailwind's utility classes in a clean, maintainable way.

My use case involves:

• A color system with semantic/grouped tokens that should map only to a specific subset of Tailwind's domains (for example, only background-color or text-color depending on their semantic intent).
• A spacing system (with its own design tokens) that needs to be mapped predictably and consistently across related Tailwind utilities (like padding, gap, size, etc.).

The new configuration approach doesn't provide a clean way to express these mappings directly. To achieve the necessary mappings, I have to generate the Tailwind config using a custom code-generation script, which is both ugly and hard to maintain. I'm forced to essentially re-implement or reverse-engineer how Tailwind generates spacing and utility classes, which feels fragile and not in the intended spirit of the framework.

Steps to Reproduce:

1. Attempt to map a complex design system (with domain-focused color and spacing tokens) to Tailwind utility domains using only the new CSS DSL config syntax.
2. Notice that there is no first-class way to control or limit how each design token maps to only certain Tailwind utility domains or property groups (e.g., ensuring a color token appears only as a background, not a border, or mapping spacing tokens only to padding/gap).
3. As a workaround, generate the config with your own code, essentially duplicating the logic that Tailwind itself uses internally.

Expected Behavior:
I'd expect to be able to use Tailwind's config and generator in a "semantic" or "domain-aware" manner, mapping complex design system tokens to only the relevant utility groups, while still taking full advantage of Tailwind's underlying generator and conventions—without having to write custom code-generation tooling. This would make working with complex/enterprise-level design systems much more maintainable and would reinforce Tailwind's place as a flexible foundation for modern web UI work.