мы используем плоскую структуру парамов, без массивов, через точку, с префиксом типа названия проекта, который может быть общий для нескольких пакетов:
`
return [
 'the-project.some-feature.enabled' => false`,
 'the-project.some-feature.name' => 'default',
];
`
так потом чуток читабельнее:
`
SomeFeature::class => [
  '__class' => ..,
  'enabled' => $params['the-project.some-feature.enabled'],
]
`
но массивами c именами пакетов, тоже ок
главное чтоб порядок был

Ну, вижу что мнения в общем сходятся. Это хорошо. @yiiliveext я тогда запишу в доку и начнём править пакеты.

Да, но подумать смогу только начиная с пятницы.

@xepozz, Wilmer, @thenotsoft, @rustamwin, @roxblnfk, @romkatsu, @viktorprogger что думаете?

В принципе норм, хотя мне больше импонирует Vendor\Package\Config::class, т.е. юзать имя класса конфига. Это даёт возможность также юзать несколько конфигов водном пакете, либо юзать несколько версий конфигов одного пакета (через наследование)
Но у нас нет классов-конфигов, поэтому и выбора нет :)

можно в github actions заставить матрицу проходить все испытания, а не останавливаться, если какой-то один упал?