This is a very confusing topic (element ordering, handedness, etc) and I am also very confused with it so bare that in mind with how valid this reply is. Firstly handedness, matrix memory layout and matrix mathematical layout are separate things which doesn't help matters.
Handedness matters in that if you want one axis to be positive right and another axis to be positive up (conventional) then the final axis either increases as it goes away in front of you (left handed) or it decreases as it goes away in front of you from you (right handed). There's then rotations to consider, do they also follow left/right handed rules (left: positive rotates clockwise, right: positive rotates anti-clockwise). You then have to take all that into account when you move things and when you setup your camera etc. With shaders I'm not entirely sure if much of that even matters now because the space is defined by you, by how you setup your transforms and projections etc. I think OpenGL being considered right-handed is based on fixed-function when you used to have all the functions for creating projections and view matricies etc. From what I've read, OpenGL actually ends up being left handed in device space anyway. It's all far too much for my head.
As far as how you lay things out in memory goes, it doesn't matter too much since mostly you will be abstracting all the maths away behind functions and operations. It doesn't affect the maths one bit (or it shouldn't). Your choice certainly has implications, row-major is convenient for accessing rows for example but then transferring that to a shader might require a transpose.
Then there's the mathematical implications of your choice and this depends on whether you consider a vector to be a horizontal or a vertical matrix. Assuming a 4x4 matrix, if you think of a vector as a vertical matrix (1 wide by 4 high for example) then when you multiply you will have to do matrix*vector but if you think of it as horizontal (e.g. 4 wide, 1 high) then you have to do vector*matrix. I don't know about HLSL but in GLSL it will decide based on the order you choose but then you may need a transpose. For example these two are the same:
// mvp was originally a column-major memory matrix
gl_Position = mvp*vec4(position, 0.0, 1.0);" // vec4 treated as a column
gl_Position = vec4(position, 0.0, 1.0)*transpose(mvp); // vec4 treated as a row
When you do your own matrix code and build, for example, a translation matrix (using a function) then you will have to decide if you will be post multiplying vectors or pre multiplying them because that will affect how you build the translation (and other transforms). You could do like GLSL does and decide based on usage but I think that just makes your code open to confusion. For example:
Matrix translation;
translation.LoadTranslation(1, 2, 3);
Vector position(0, 0, 0);
Vector a = position*translation;
Vector b = translation*position;
Both of those can be coded to work just like in GLSL but only one will work as intended and that depends on how you built the translation matrix. You would have to transpose one to make it work as intended.
There are pros and cons to all choices but as long as you are consistent I don't think it matters too much. I wish there was some full blown article that covered all these things because I'm still not 100% sure of any of it either. Hopefully someone here has more of a clue than I do.
