Крутой, доскональный анализ! Долго эта проблема ждала его)

Я бы только поспорил с некоторыми предлагаемыми правками.

По сути, сейчас у нас есть 3 состояния: Ссылка, Кнопка и Кнопка-Ссылка.
Но проп displayAs добавит ещё одно - Ссылка-Кнопка:

<Link displayAs="button" /> 

Т.е. визуально это будет Кнопка, но функционально Ссылка.

Соглашусь с синхронизацией пропа use. С введением неинтерактивной ссылки и варнинга если проп onClick задан без пропа href.
Но далее предлагаю ограничится новыми пропами только для Button:

• вынести функциональность use="link" в отдельный проп, типа asLink
• добавить проп href, который позволит делать состояние Ссылка-Кнопка. т.е. банально менять внутри <button /> на <a />.

Кажется, что такое будет проще реализовать, и поддерживать. И также разработчикам нагляднее пользоваться.

Нашёл отличный сайт, на котором можно посмотреть можно ли вложить один тэг в другой.

прокомментирую здесь, "неинтерактивная ссылка" это оксюморон, не нужно его использовать.

не читал весь анализ, но удобное апи должно выглядеть так (назовем элемент Clickable):

• as — пропса, которая говорит что должно быть корневым элементом (можно передавать теги или реакт компоненты, например Link из react-router).

<>
  <Clickable as="button" onClick={console.log} />
  <Clickable as="a" href="/href" target="_blank" onClick={console.log} />
  <Clickable as={Link} to={{ path: "/href" }} onClick={console.log} />
</>

• variant — пропса, которая говорит как выглядит контрол (закрашенный вид, вид с обводкой, вид просто текста, и тд)

<>
  <Clickable as="button" variant="outlined" onClick={console.log} />
  <Clickable as="a" variant="filled" href="/href" target="_blank" onClick={console.log} />
  <Clickable as={Link} variant="text" to={{ path: "/href" }} onClick={console.log} />
</>

при этом не стоит стараться отгадать за пользователя какой элемент нужно рисовать, лучше всегда требовать пропсу as, потому что в реальной жизни комбинаторика вариантов слишком большая (всякие styled компоненты, компоненты-обертки, дивы, input type=submit-ы и тд)

неплохой пример есть у Material UI: https://mui.com/material-ui/react-button/

Тоже прокомментирую, анализ прочитал. Очень круто разобрано, это большая работа. Спасибо.
Но не со всем согласен.

1. Нужно уточнить

Непонятно что имели в ввиду в гайдах под фразой

У ссылки должна быть кликабельная область как у кнопки

Это не так. В интерфейсах прямо сейчас встречаются инлайн-кнопки в тексте.
Пример, в тексте может быть фраза "обратитесь в техподдержку", на слове "техподдержка" кнопка, которая открывает чат в виджете техподдержки.

2. Общие правки 1.

Не согласен с дизайном контракта. Проп displayAs не решит проблему, у кнопок гораздо больше вариантов, чем есть сейчас.
Пример из гайдов, такого use сейчас нет, нужно будет добавлять новое значение. Похоже, что это вариант из пункта 1.

3. Общие правки 1.1.

Контрол Button с displayAs="link" это не совсем то же самое, что контрол Link с displayAs="link". Согласно 4-му постулату в таком случае у контрола Button кликабельная область должна быть больше, чем у контрола Link.

Это не так. Автор гайда упускает большой пласт сценариев с инлайн-кнопками. В пункте 1 я привёл пример.
Не нужно на это ориентироваться, это сломает текущие практики и поведение, которое используется в проектах уже сейчас. Кажется, стоит эти моменты обсудить с проектировщиками, напомнить / рассказать что есть сейчас. Новый гайд выглядит оторванным от реальности. Путаются кнопки / ссылки, смешиваются внешний вид и поведение. Нужно разделять внешний вид и поведение. Нужно дать обратную связь и скорректировать технические моменты.

4. Общие правки 2.

Не получится унифицировать пропы, они не идентичны. button use default это не grayed. Кнопка белая. Такое сопоставление неинтуитивно. Это натягивание совы на глобус.

Лучшим решением было бы избавляться от use, либо расширять его. Например, создать единый список представлений кликабельных контролов: button-default, button-primary, link-success и т.д. . Старые значения (временно) оставить для обратной совместимости.

Но давайте посчитаем сколько видов кнопок есть сейчас и будем помнить что фантазия проектировщиков неудержима. Проектировщики решают свои интерфейсные задачи и в любой момент может появиться необходимость в новом представлении для контрола. Где-то новое представление необходимо, где-то может показаться избыточным, нужно смотреть конкретный сценарий.
С точки зрения библиотеки контролов же нужно помнить, что всё что попадёт в use нужно будет поддерживать в будущем. Поэтому вариант унификации / расширения use именно в таком виде выглядит весьма сомнительным.

5. Правки Link 1.

Согласно 6-му постулату: "Контрол Link должен выбрасывать ошибку, при попытке передачи атрибута onClick без атрибута href.".

Категорически против самого постулата и решения бросать ошибку.

Не нужно бросать runtime ошибку, неправильно создавать разработчикам проблемы на ровном месте.
Лучше не мешать работать, а рекомендовать хорошие практики.
Достаточно дать совет в документации. Описать "гигиенический минимум" разработчика, что-нибудь вроде

"не используйте ссылку без свойства href, это противоречит спецификации и мешает доступности вашего интерфейса. Лучше применить кнопку".

В пункте приведён отличный пример с кодом, который можно перенести в документацию.

Если хотим ограничить использование - лучше это сделать на уровне тайпингов.

6. Правки Link 2

Согласен с @nulladdict, что "неинтерактивная ссылка" это оксюморон.

Не согласен с предложением в анализе, что для этого кейса нужно описывать отдельное поведение. Всё не зарегулировать.

7. Правки Link 4

Не согласен с

"Если передан проп size, но displayAs="link" - должна быть выброшена ошибка."

Контролы не должны наказывать разработчика. Они должны быть инструментом, который упрощает работу, а не инструментом с которым приходится бороться.

Повторюсь, что направление развития контролов через дополнительный проп displayAs кажется сомнительным. Помимо size и use появляется дополнительный проп displayAs, а это дополнительный множитель для вариантов, которые придётся поддерживать: use * size * displayAs. Это запутает и усложнит работу с контролом как для рядовых разработчиков, так и для команды поддерживающей контролы.

Что в итоге?

• в гайдах есть сомнительные утверждения, хочется уточнить что имели ввиду и возможно внести правки в гайд, чтобы и у разработчиков, и проектировщиков было одинаковое представление
• считаю, displayAs не решит проблем, а только увеличит сложность как для потребителя, так и для команды, которая развивает контролы
• текущий подход с use перестает удовлетворять требованиям, становится не гибким, количество вариантов растёт
• Не нужно лишней регуляции. Контролы не должны бросать ошибки в рантайме. Есть исключения, например, контрол для ввода валюты. Точность значения при работе с деньгами очень важна для бизнес-сденария. Для кнопок и ссылок в этом нет необходимости.

Предложения

Различие между кнопкой и ссылкой сильно размыто. Дизайнеру важно как контрол выглядит и как работает. При этом разработчик, на мой взгляд, стоит понимать что нужно использовать в конкретной ситуации. Какой контрол применить чтобы пользовательский опыт был максимально доступным.

Считаю что пора отделить внешний вид контрола от функциональной принадлежности.

Предлагаю оставить два контрола Link и Button, чтобы разработчик понимал что будет корневым элементом и какие атрибуты у него есть.
Визуальное же представление пора объединить в один интерфейс. Чтобы можно было передавать его и в кнопку и ссылку.

Как это можно сделать:

• Описать все визуальные свойства кнопки и ссылки моделью
  • принцип как сейчас в теме, только без привязки к конкретному use (primary, pay)
  • так свойств будет меньше, проще найти нужный. Сейчас искать нужную переменную в теме – ад.
• Определить дефолтный вид для ссылки и для кнопки
• Разрешить менять дефолтный вид частичной моделью (как в теме)
• Подготовить стандартные view для типовых кнопок

По сути предлагаю передавать в контрол маленькую локальную тему.

interface ClickableViewStyles {
  display?: 'inline' | 'inline-block';
  textDecoration?: CSSProperties['textDecoration'];
  border?: string;
  background?: string;
  /* ... */
}

interface ClickableView {
  default: ClickableViewStyles;
  hover?: ClickableViewStyles;
  focus?: ClickableViewStyles;
  active?: ClickableViewStyles;
}


const PrimaryButtonView {
  default: {
    background: "lightBlue"
  },
  hover: {
    background: "blue"
  },
  active: {
    background: "darkBlue"
  }
}

/* ------------ */
import { PrimaryButtonView } from '@skbkontur/react-ui';
import { MyProjectButtonView } from '../controls/buttons';

<Button use={PrimaryButtonView}>Подписать важный документ</>
<Link use={PrimaryButtonView}>Перейти к самому важному разделу</>

<Button use={MyProjectButtonView}>Создать что-то</Button>

Вот ещё сценарий на подумать.

Элемент, при клике на который происходит браузерное pop (если есть куда идти) или replace (если пользователь пришел по прямой ссылке)

Очевидно, что под капотом должен быть тег a, потому что у места куда этот элемент ведет есть адрес. При этот основное действие (push этого адреса) никогда не происходит, потому что ломает браузерную историю. При этом пользователь может захотеть открыть «предыдущую» страницу в новой вкладке, поэтому это точно не button.

Встречается в логически вложенных страницах (переход из списка статей в статью и обратно) и всяких модалках/сайдпеждах, которые умеют открываться в разных контекстах (как в стаффе/инсте/твиттере)