Yeah, we dropped the edit date convention, but there are still files that haven't been updated accordingly.

I agree with bringing the heading and license comments over though!

Our convention is to place names alphabetically by last name, principally to avoid debates about prominence of names.

I don't recommend naming a class "Refactored". Just replace the old version. We're using Git, so you can always see the old versions.

Can rows and columns ever be negative? If not, make the parameters unsigned int, or even better, size_t (an unsigned integer type used by most data structures for indices and lengths.)

If you make the above change, you'll also want to change the type here from int to size_t.

Additionally, I recommend using prepended increment/decrement anytime the return value from the operation is not directly used, as ++i is one less CPU instruction than i++. The compiler usually optimizes this out anyway, but it's good to be in the habit for the rare scenario when it doesn't.

You need a documentation comment on each function. Documentation comments are either /// ... or /** ... */. For normal functions (as opposed to constructors), you also need to describe all the parameters (\param) and the return value (\return), as appropriate.

Comments inside functions should be ordinary comments //, not doc comments.

Switch from spaces to tabs across all your files, please. Visual Studio Code can do this for you, and then clangformat can help with the rest of the formatting. Talk to @ardunster on how to do that.

Since this is syntactically correct with Eigen (apparently), you may need to silence the linter on this topic like this.

...and here.

You can find the rest.

This is rather odd to me. What actually happens if you combine these lines together? (I know this wasn't your code.)