Isn't there a contradiction between the pop_column function, which remove one column from every matrix, and pop_compat, which remove one column from compatible rows but also remove incompatible rows? Maybe keeping specialize_compat as a name would be clearer here.
Similarly, pop and pop_column have a slightly different meaning for their common pop root since only pop returns the dropped leftmost element(s), but this sounds like a minor discrepancy at most.

Yes, I kept the names that were already there, but I guess just specialize would be a decent name.

There is also val pop : ... which pops the first matrix from the list... Perhaps pop_column should become pop_first_column_of_matrices?

Another possibility might be specialize_for_var to describe the use case rather than the implementation?

pop_compat is the composition of pop_column and filter_compat (or guard_compat). I don't think that specialize is more informative as a name, and I'm not fond of the longer names proposed (pop_first_column_of_matrices should be map_rows pop); maybe just implement filter_compat and write the composition by hand? (It's one more traversal of the whatever, but it doesn't actually matter much.)

@trefis and myself have discussed better interfaces for matchers, in particular pattern -> pattern list (where NoMatch is the empty list and OrPat returns a list of explosions) and a version where OrPat is removed (replaced by generic handling of or-patterns in the specialization code), allowing pattern -> pattern option. I think that at this point it may be possible to keep only specialize in the module, and write the matchers nicely in the client code, obviating the need for those API naming discussions.

In the meantime, my inclination would be to keep the names as they currently are to keep the refactoring train going.

It is most probably a good idea to let the refactoring train go on. And, maybe, or not, I will have a look at the end of the refactorization tunnel to see if those names are still here.