I haven't used dash/s/f much, but from what I see they do try to bring a
more "flat" style of APIs, following the style of Clojure. There are a
lot of utility functions in there too (like extra abstractions on top of
the basics that the authors found to be useful). So when you ask the
core library to be more like f.el, you'll have to specify what exactly
you'd like to see changed: rename existing functions dealing with files
to start with file-* or to add new ones. Then we can work out some sort
of policy to adopt (or not) such changes.
I think the crux of the issue regarding existing Emacs lisp would be "should all file related apis start with file- ?"
If we decide the answer is yes (as advised by the coding conventions) we could start by simply aliasing the existing API that does not follow this convention. That'd mean `copy-alist` would be aliased as `alist-copy`, do you think people would be strongly against this?
Also, quite a bit of functions seem to be named with the purpose of
keeping the names short, perhaps too short, like the author came over
from Clojure, found out that you can't simply
(require '[string-utils :as s])
Yes, I think "string-" is better than "s-", but I understand the author didn't want to clash with the existing "string-" functions so he picked "s-".
In this case I think a simple proposal would be to list all the "s-" functions that don't have a corresponding "string-" function (s-truncate, s-left, s-right, etc) and propose them for inclusion but named under the "string-" namespace.
Regards,
Philippe