Como você decide se algo pertence ao design system ou continua sendo caso isolado?

Use evidência de repetição, não palpite. Um padrão ganha lugar no sistema quando apareceu em três ou mais contextos reais, quando o comportamento dele é estável, e quando alguém vai ser dono dele. Entregue o caso isolado primeiro, deixe ele se provar, e depois promova com props, estados e orientação de uso claros. Componentes prematuros criam abstrações contra as quais o time briga por anos.

Minha regra de bolso é a regra de três. Na primeira vez eu só construo. Na segunda, eu anoto a duplicação. Na terceira, eu olho as três e pergunto se são realmente a mesma coisa ou três coisas que por acaso se parecem. Essa última pergunta importa, porque a falha clássica de design system é fundir dois padrões porque eles parecem parecidos e depois pendurar uma variante toda vez que eles divergem, até você ter um componente com nove props booleanas que ninguém consegue usar com segurança. Quando eu promovo algo, vem com um contrato de verdade: os estados incluindo carregando, vazio, erro e desabilitado, as regras de conteúdo, e uma seção curta de 'não use isso para', que evita mais bagunça do que a orientação de uso. E precisa de um dono. Num time a gente entregou um sistema lindo que apodreceu em um ano porque ninguém era dono, então os times forkavam componentes localmente e depois de dezoito meses tínhamos quatro tipos de dropdown de novo. Governança é sem glamour, mas é o trabalho de verdade.