На самом деле ничто не мешает вам иметь несколько ResourceManager'ов, но, как вы говорите, оно было разработано для 18n. Лично у меня было много проблем с рексом, особенно когда речь шла о сателлитных сборках GAC и развертывании. Другая проблема, с которой я сталкиваюсь, - это жесткость этой системы. Если вам когда-нибудь понадобится новая строка, вам нужно перекомпилировать dll и разбираться с xml, ваши клиенты не будут гибко подходить к исправлению вещей, к тому же что-то, что съедает время.
Решение, основанное на иерархии, которое есть у resx, означает, что оно переключится с «en-US» на «en» и, наконец, на инвариант, у вас не будет больше откатов, чем вы, и вы не сможете определить два разных «en» США "в одном файле ресурсов для той же строки. Вы можете взломать это решение, чтобы использовать «en-US» для клиента X и «en-AU» для клиента Y, а затем отправить его как один ресурс, но это чертовски грязно.
Вы можете собрать разные сателлитные сборки для каждого клиента и заставить это работать как-то.
Лично я предпочитаю решение на основе базы данных для локализации с использованием sqlite или mssql и обеспечения выполнения некоторого кэширования после первоначального поиска строк.