Внутренним API тоже нужна обратная совместимость?

Буквально недавно перед одним из наших экспертов стояла задача доработать метод API таким образом, что он потерял обратную совместимость со своей прежним видом (добавили path параметр)

С одной стороны всё просто: API принадлежит одной команде, можно быстро договориться, а при необходимости одновременно обновить фронты и бэки

Но ситуация была неоднозначная

🟢 Позиция «Выкатим все одновременно и нормально»
Внутренние API не обязаны жить вечно. Если контракт используется несколькими сервисами одной команды, можно синхронно внести изменения, быстро обновить потребителей и удалить старую версию.
Полная обратная совместимость здесь может только замедлять развитие: появляются лишние версии, временные поля и поддержка устаревших сценариев

🔴 Позиция «правила должны быть как для внешних, так и для внутренних API»
Внутренний API это тоже контракт. Про некоторых потребителей мы могли забыть, команды меняются, зависимости не всегда очевидны, а синхронное обновление всех сервисов часто невозможно.
Это проблема особенно если сервисы разворачиваются независимо и если нашли баги в одном и откатываем релиз, то и второй сервис тоже должны откатить. Поэтому нужны версионирование, правила изменения контрактов и период миграции

А как у вас: внутренний API можно менять свободнее или обратная совместимость должна быть обязательным правилом для всех интеграций?