Exercise 2: The Naming Problem and the Dead-CSS Problem, and How Each Is Addressed — Possible Solution
====================================================================

THE NAMING PROBLEM
------------------------------
Per this chapter, "BEM makes naming consistent, but it doesn't make it
easy — every new component still needs someone to invent .card,
.card__header, .card__title, and hold a mental model of what CSS
rules live where." Every time a developer builds a new component under
a BEM-style system, they still face the real, ongoing cognitive task of
inventing appropriate, meaningful, non-colliding names for that
component and each of its own pieces — a task that has to be repeated
for every new component, indefinitely.

HOW UTILITY-FIRST ADDRESSES IT
------------------------------
Per this chapter, "utility classes eliminate this naming step almost
entirely, since the classes are already predefined, standardized, and
reused everywhere." Because the available classes (p-4, flex, and so
on) already exist as a fixed, shared vocabulary before any specific
component is even built, a developer building a new component never
has to invent a NEW class name at all — they simply select from the
already-existing set. The naming decision is made once, by the
framework's own designers, rather than repeatedly, by every developer,
for every new component.

THE DEAD-CSS PROBLEM
------------------------------
Per this chapter, "with semantic classes, a project can accumulate
.card-v2, .card-alt, .old-card-style rules over time that may or may
not still be used anywhere — genuinely hard to know what's safe to
delete." Because each semantic class is custom-built for one specific
use case, when that use case changes or a component is redesigned, the
OLD class rule often isn't deleted (out of uncertainty about whether
it's still referenced somewhere else) — it just accumulates alongside
the new one, over and over, as a project evolves.

HOW UTILITY-FIRST ADDRESSES IT
------------------------------
Per this chapter, "utility classes are inherently reused across many
elements, so there's no equivalent 'dead' utility CSS accumulating the
same way." Because a utility class like p-4 is shared across
potentially hundreds of different elements throughout an entire
project rather than being built for one specific component, there's no
meaningful sense in which a SPECIFIC utility class becomes "dead" the
way a component-specific class can — the class continues to be
genuinely, actively used elsewhere even after any one particular
component using it is redesigned or removed.

WHY THIS WORKS AS AN ANSWER
------------------------------
It states both problems using the chapter's own precise wording, and
explains the specific mechanism (a pre-existing shared vocabulary
requiring no invention; broad reuse preventing true "dead" classes)
by which utility-first addresses each one individually.