Отвечаю на свои вопросы. Раскопал
1. lc_ctype (для всяких нумераций и точек), lc_collate (для сортировки) Postgres умеет только те, что умеет glibc и установлены в системе. Т.е. он использует системные. С этим связаны и попытки стандартного клиента воспользоваться ими же. Поскольку исторически в Postgres зачем-то кувалдой вбита идеология системный пользователь === пользователю баз данных. Соответственно, если у вас в системе есть локаль, которая отсортирует и русский язык, и en_US и ss которая ß, то ок, нет - нет. Есть ли такое в Linux я хз. Похоже C.UTF-8, но я не уверен. Это такой вопрос для отдельного исследования и решение спорное.
2. encoding соответственно для хранения - то что прошито
http://www.postgresql.org/docs/current/static/multibyte.html (и там таблицы соответствия). Походе UTF-8 он таки алиасит UTF8 и можно и так, и так писать. encoding используется для хранения и для конвертации между сервером и клиентом. Чтобы была конвертация, надо на клиенте сделать SET NAMES "блабла". Postgres достаточно однозначный - или конвертация есть, или её нет, голову сломать сложно. Имплементация кодировки и переконвертации свои, не системные (и таблицы свои, и вот это перечесление свое).
3. Кодировку/локаль если задали, то всё. Если какой-нибудь окорок запихал докером докер через докер чтобы докер SQL_ASCII или LC_COLLATE C - то это навсегда. И таких окороков 145%. Дамп, прибили базу, создали заново с новыми параметрами, залили обратно дамп. Это может и хорошо. Никогда не доверял это ALTER TABLE.