subr-x.el code and defsubst [was: Trimming strings, /.../subr-x.el modification]

[Drew Adams]

> > The code will be byte-compiled.  I see zero reason why these
> > functions should be defsubsts.
> 
> The reason, AFAIC is the following: subr-x holds functions which we
> haven't committed to adding to core.  We exceptionally allow them to
> not use a prefix but in return we only use subr-x while compiling (since
> it's fundamentally not namespace-clean and we don't want to impose those
> non-clean names upon the unsuspecting user).

OK.  Not a great reason, IMO, but I understand now, at least.

I don't think that reason is obvious.  Please consider adding a
GIANT comment in subr-x.el to explain this exceptional treatment.

This existing comment, which is all there is, does not cover it, IMO:

;; Less commonly used functions that complement basic APIs, often
;; implemented in C code (like hash-tables and strings), and are
;; not eligible for inclusion in subr.el.

;; Do not document these functions in the lispref.
;; http://lists.gnu.org/archive/html/emacs-devel/2014-01/msg01006.html

And why is it that this library has still not been "committed to
core"?  (And isn't that what GNU ELPA is for?)

Beyond that, this approach of not bothering with name prefixes,
byte-compiling separately, etc. seems really weird (fragile, error
prone).  Why such an exception?  Is this really the best way to
handle code that you consider "experimental" or "less commonly used"
or code "that complements basic APIs"?