Здравствуйте, rm822, Вы писали:

R>Дело не в производительности, а в том что dllimport предназначался для winapi, это слишком топорный инструмент чтобы отмаршалить скажем
R>

R> std::vector<COLORREF> GetPalettte(const std::wstring& name)
R>

R>не говоря уже о более сложных случаях (ну или я что-то не знаю)

То, о чём Вы пишите (работа с winapi через dllimport) именуется PInvoke (Platform Invocation Services):
https://en.wikipedia.org/wiki/Platform_Invocation_Services
http://www.pinvoke.net/default.aspx/ntdsapi.DsBind

Впрочем, это не мешает применять .NET аттрибут dllimport и для других (в т.ч. и самописных) DLL.

При этом, в аргументах методов/функций могут применяться не только POD типы:
https://msdn.microsoft.com/en-us/library/ef4c3t39.aspx
https://www.gamedev.net/forums/topic/556938-pinvoke---passing-an-array-of-structs
в том числе и строковые:
https://msdn.microsoft.com/en-us/library/s97shtze.aspx

Насчёт STL коллекций — думаю, что их потребуется передавать как простой массив (в стиле ANSI_C).

P.S. Что же касается производительности при выполнении кода, то здесь всё зависит от класса разрабатываемого приложения:
— если для бухгалтерии и документооборота на производительность можно и не обращать внимания;
— то для технических и научных приложений, для приложений моделирования — производительность НЕ ПУСТОЙ звук!
Вот и получается, что для определённогокласса приложений: нативный C++ видится как оптимальный выбор.