Nice, I just saw this as I wanted to create my own PR with the same fix. One question:

The order in +fold/{open,close}-all is ts-fold -> vimish-fold -> hideshow -> outline. Should the order in +fold/{toggle,open,close} be the same? You have outline and hideshow swapped right now. I don't know if it makes a difference.

I found a few other issues with fold as well:

• +fold/open-rec acts like +fold/open-all because the (beg end) arguments are unused in some places. I can make my own PR for this.
• +fold/next doesn't work, but +fold/previous does. Still need to figure this out.

The order in +fold/{open,close}-all is ts-fold -> vimish-fold -> hideshow -> outline. Should the order in +fold/{toggle,open,close} be the same? You have outline and hideshow swapped right now. I don't know if it makes a difference.

Updated. Thanks for the reminder.

* `+fold/next` doesn't work, but `+fold/previous` does. Still need to figure this out.

I think the reason for this is that the (overlays-in (point) (point-max)) for +fold/next always includes the current point's fold, thus causing it to get stuck in place.

A quick fix might be:

@@ -275,7 +275,8 @@ region."
                                        (eq (overlay-get ov 'creator) 'ts-fold))
                                      ;; `overlays-in' does not provide a list that is sorted
                                      ;; (in the way we need it atleast) so we need to sort it based on direction
-                                     (cl-sort (apply #'overlays-in arg-list) comp-fun :key #'overlay-start))))
+                                     (cl-sort (apply #'overlays-in arg-list) comp-fun :key #'overlay-start)))
+                               (ovs (if (> count 0) (cdr ovs) ovs)))
                           (if (and ovs (<= (abs count) (length ovs)))
                               (goto-char (overlay-start (nth (- (abs count) 1) ovs))))))))
            if (save-excursion (funcall fn))