Hmm, Thanks for your reply! I decided to not incorporate them yet since I was trying to maintain 8.2.0 compatibility. I use this for an internal project which has that dependency. 
Besides, I want to know if it’s possible to get SoA access to the points, instead of the tuples x0,y0,z0|x1,y1,z1| so on… Is there a way to get a pointer to all the X’s, Y’s, Z’s? I’m aware that I’m asking for an SoA layout in a construct that was meant to abstract away such layouts! This might help reduce the start up time where I cache a triangle’s x, y coordinates (SoA and AoS), scalars into STL vectors. For large meshes (>100k verts) this takes significant time.
Speaking about start up costs and caching triangles inside STL vectors, here’s another question. What happens when I resize the data array within the functor. So, I’d want the existing points to remain and some extra space to be allocated/reserved(?). Does this deallocate, allocate and copy over all the points? I’m looking for something similar to STL vector’s reserve.
If there’s no copy, I could directly write to the points, scalars data arrays. At the moment, I reserve a big enough STL vector of templated TriMeta somewhere in the beginning to cache existing triangles and simultaneously fill up new ones. So, apart from the start up performance hit with this approach, it’s a bit of a mess to keep track of a specific triangle with its data, indices. I’ve a hunch the situation might be better if I could directly work with the data array accessors or ranges.