Great stuff. As to why transpose, here is an OLTP example.

True transpose is useful to simplify several patterns. My fav was a test specification system where new tests came an went at technician's whims. The tests were in an ever changing list. Data needed to be captured in a grid, so test names transposed to columns and instances of results became rows. But storing results needed to be a row with test name and value. So spec transposed to result grid which transposed to the saved data. Oh, and the tests were in sets.

Easy in an array language, not so easy in relational. Arrays have implied axis that are not part of the array per se. Each position can be named, like an enum. In relational, the column axis is part of the meta. They are essentially enum named positions. Rows are ignored in the meta, which is correct as far as relational theory goes. In practice auto-identity and row_number() show up a lot, implying array like processing is desirable. Rows have business keys or surrogate keys or occasionally none at all. Row keys are akin to column names and like column names can be paired with positions. That is the key is an enum for a position.

By analogy, just like meta data for columns, meta data for rows makes sense. In the test specification system, we took advantage of row meta by naming the row positions as a composite of business keys. That simplified code. The row meta can be just a table 1-to-1 with rows of the original.

Having column and row meta data opens up emulating array transposes. That is (row, col) becomes (col,row). Perhaps some clever guy has or can make a fast way to use that fact to perform a transpose.

The ideal transpose will recreate the original when transposed back.

We also used dynamic sql, but without while loops. SQL imposed a column limit, thus a row limit, at the time I believe it was 1024 columns. It might be worthwhile to dynamically create an inline table valued function simply because Insert-Exec is so inelegant.