Thanks for preparing this! While it's an edge case, could you please extend it so that it works with arbitrarily many dimnames (e.g. a 3D array like array(NA, dim = c(2, 2, 2), dimnames = list(c("A", "B"), c("C", "D"), c("E", "F"))))?

I would do that with lapply on the output of dimnames so that it is generic for as many dimnames as come out.

Codecov Report

Merging #483 (da3630b) into main (ab90c1a) will increase coverage by 0.46%.
The diff coverage is 100.00%.

@@             Coverage Diff             @@
##             main      #483      +/-   ##
===========================================
+ Coverage   99.53%   100.00%   +0.46%     
===========================================
  Files          23        23              
  Lines        1084      1088       +4     
===========================================
+ Hits         1079      1088       +9     
+ Misses          5         0       -5     

Good point indeed!
I never use arrays but I agree this should be as generic as possible.

I re-used your case as a test, testing that the output is lowercase should be enough. My other tests were maybe a bit overkill, as I'm re-testing make_clean_names() features, I could remove them if needed.

With that one last change, I think we'd be good to merge. @sfirke any other things you see?

There you are, this should do 👍

As a side comment, here is a quote from the book "Advanced R":

One of the challenges of error handling in R is that most functions generate one of the built-in conditions, which contain only a message and a call. That means that if you want to detect a specific type of error, you can only work with the text of the error message. This is error-prone, not only because the message might change over time, but also because messages can be translated into other languages.

Indeed, when you test your errors, you often rely on regexp. This means you cannot change the error/warning message as you might want. Since you already import rlang, you could swap every stop("foobar") to rlang::abort("foobar", class="..."), so that you can then call expect_error(expr, class="...") (and same for warnings).
I did that in my package crosstable a while ago and found this refactor was really worth it.

@DanChaltiel , I wish that all messages, warnings, and errors were classed, so that testing would be better, as you suggest. I've started using classed messages, warnings, and errors some of the time in my code. It is helpful. If you add classes, please make the class name start with the package name so that there is a near-zero chance of conflicts.

Good idea on the classing of errors, Dan. Thanks for this PR and for being receptive to tweaks! I'm merging it now.