I agree.  Not sure if the `read-library' function should go in a 
different file, but in any case it makes sense to let users take 
advantage of it in their code.


Attached is a revised patch with Philipp's other suggestions taken into 
account.


On 07/05/2017 17:07, Drew Adams wrote:
>> - Consider renaming `find-library-read' to
>>    `find-func--read-library' to make it internal.
>>    It's probably not intended as a public API.
> Why?  No.  Please do not consider that.  Not for a moment.
>
> FWIW, I completely disagree with this point of view and
> approach to Emacs Lisp.  Just the opposite.  Unless there is
> some _very_ important reason why something _must_ be branded
> as "internal", it should not be.
>
> It may be a hard habit to break, but the notion of a "public
> API" is generally inappropriate for Emacs Lisp.  Emacs users
> are also Emacs-Lisp developers. And yes, they do write their
> own libraries that read input.
>
> Just imagine, if an input-reading function such as
> `ffap-read-file-or-url', `read-file-name', `completing-read',
> `read-face-name', or `read-char' were declared at the outset
> to be "internal".  What's the point of such an artificial
> separation?
>
> In fact, I'd suggest that the library prefix be removed from
> `find-library-read' - just call it `read-library-name'.
> Elevate it; don't hide or suppress it.
>
> GNU Emacs in particular, and free software in general, have
> the explicit intention that users _are_ developers and that
> they look under the hood, tinker with engine parts, modify
> or make their own use of them, to create new and better
> things.
>
> And yes, Emacs development is driven not only by its
> maintainers or those most active in its C code or fixing
> its bugs.  It is driven also, and importantly, by users,
> who write their own code for their own uses, and who
> sometimes extend that code into 3rd-party libraries.
>
> Some such development even finds its way into distributed
> Emacs itself - either directly, by incorporating it, or
> indirectly, by copy or inspiration.  The latter happens
> more than most people, including Emacs maintainers, are
> aware of.
>
> Emacs would not be what it is today if it did not offer
> features written by its users (think Org).  And this has
> been true of Emacs since Day One - even before GNU Emacs.
>
> So let's please stop with the tendency to view Emacs
> development as an internal-vs-external thing: we core
> developers and the code we maintain vs you "lusers" and
> your customizations.
>
> If we are to have _any_ "internal" functions or variables
> then the burden should be to demonstrate strongly why
> a given one really _needs_ to be internal.  A priori,
> every single one should be "external" or, more exactly,
> "nil-ternal".
>
> I see no good reason why a general function that reads a
> library name should be flagged "internal".  Why should
> anyone be discouraged from using it in their code?  Why
> shouldn't everyone be encouraged to use it, if they want
> to read a library name?
>
> This kind of not-for-the-users attitude smacks of
> elitism, or at least seems control-freakish, even if it
> is unconscious.  Open the corral, please.  Emacs, and
> all of its code, belongs to its users.
>
> There is nothing special about this function.  It is
> useful generally.  And it should be called something
> like `read-library-name'.