Florian Weimer wrote:
> > But it means that we cannot promise that these .h files are even remotely
> > stable APIs.
> 
> I must say I was surprised to see dynarray and scratch_buffer end up in
> gnulib.  I never intended them to escape this way from glibc.  The
> interfaces and their implementation are problematic in some ways, and I
> can't recommend them for general use.

Thanks for this clear statement, Florian.

So I was too optimistic when I wrote
  - "It looks like the 'scratch_buffer' could be useful to some programs
     outside of glibc." [1]
  - "dynarray looks useful" [2]

Here are proposed patches to rename the modules.

[1] https://lists.gnu.org/archive/html/bug-gnulib/2021-02/msg00073.html
[2] https://lists.gnu.org/archive/html/bug-gnulib/2021-03/msg00042.html


2022-11-03  Bruno Haible  <bruno@clisp.org>

	dynarray: Rename to glibc-internal/dynarray.
	* modules/glibc-internal/dynarray: Renamed from modules/dynarray.
	* modules/glibc-internal/dynarray-tests: Renamed from
	modules/dynarray-tests.
	* modules/regex (Depends-on): Update.
	* NEWS: Mention this change and the previous one.

2022-11-03  Bruno Haible  <bruno@clisp.org>

	scratch_buffer: Rename to glibc-internal/scratch_buffer.
	* modules/glibc-internal/scratch_buffer: Renamed from
	modules/scratch_buffer.
	* modules/glibc-internal/scratch_buffer-tests: Renamed from
	modules/scratch_buffer-tests.
	* modules/canonicalize (Depends-on): Update.
	* modules/canonicalize-lgpl (Depends-on): Likewise.
	* modules/glob (Depends-on): Likewise.