We've been dogmatically following the guideline of putting the 'proc'
argument first in procedures derived from map, for-each, etc., despite
that their hash table variants don't take multiple hash tables.

Am I the only one thinking

    (hash-table-for-each foobar
      (lambda (key value)
        (do something with key and value)))

looks much nicer than

    (hash-table-for-each
      (lambda (key value)
        (do something with key and value))
      foobar)

?

SRFI-69 avoids the issue by calling it "walk" instead of "for-each."
Can't we just break from the convention here and do what makes sense?
The worst thing that can happen is "error: wrong type argument: expected
hash table, got procedure."

Hash-table-fold would take 'hashtable, init, proc' like

    (hash-table-fold ht '()
      (lambda (key value acc)
        (cons (cons key value) acc)))

which looks a lot nicer than the

    (hash-table-fold
     '()
     (lambda (key value acc)
       (cons (cons key value) acc))
     ht)

that one would currently use.  (Or with the '() on the same line as
hash-table-fold, and the others lined up, which wastes a ton of
horizontal space.)

I don't think there's too much space for confusion because I already get
conscious over the argument order in uses of map and for-each all the
time because they make it such a pain in the back to get the code
readable.  And using hash tables already feels significantly different
from using lists or vectors for several reasons.  (Do note the
over-arching theme of SRFI-125 trying to imitate SRFI-1 with awkward
results, or the even wider over-arching theme of forcing consistency
where it doesn't necessarily make sense, like adding make-list,
list-set!, etc. to R7RS-small...)

I'll be bold and release the next draft of SRFI-126 with the orders all
changed.  I'll revert it if there are strong objections with good
points.  (They might be necessarily subjective, like "I'm sure people
will confuse the order" without empiric evidence, but that's fine; speak
your mind please.)

Taylan