I’m not especially familiar with the native providers but I get the broad point. There will always be compromises between design goals (e.g. performance and flexibility) and it’s perhaps a more difficult balance to find in managed languages/runtime, e.g. in C/C++ we could get a pointer to a matrix column and treat it as an array (which it is); we can do this in dotNET but that requires using the ‘unsafe’ compiler switch and pinned objects, so there’s already considerations there which you don’t have in the unmanaged world. And of course a row vector causes indirection in the accesses due to the column major ordering of the matrix, so probably just as well to copy in that case to obtain good CPU cache coherency (depending on how many accesses will be made on the vector)
Incidental, are you aware of the less than ideal performance in dotNET of multi-dimensional arrays compared to jagged arrays? One option is to use jagged arrays as matrix storage, but the issue there is (A) the storage is not guaranteed to be in a contiguous block, and (B) it’s optimising around what is arguably a fixable issue in the platform (the CLR, compilers and the framework classes).
On balance copying into vectors is probably the best approach. I was thinking that a vector view/window onto a column (i.e. in line with the column major ordering) would be nice in some cases, and that the performance for simple accessing would be OK if the getters and setters were all inlined by the JITter (assuming the inlining works over multiple levels/layers of s getters/setters).