RE: "whether the global keymap C-x 4 will be replaced by a command,"

[Drew Adams]

> the feedback I got was that it would be better to
> avoid cluttering the function symbol namespace with
> lots of -other-window commands.

My feedback is that I _want_ separate other-window
(and other-frame) commands.  Explicit commands.

But _not_ in some general, apply-to-all-commands (or
all commands that show something in a window or select
a window).

I want such commands only when and where I want them,
and I want them bound to keys only when and where I
want such bindings.  I don't want something to create
such other-* commands willy nilly, automatically.

IOW, I want just what we have now:

. ability for anyone to explicitly define an other-*
  command

. ability for anyone to bind any same-* or other-*
  command to any key in any mode or other context.

. ability for anyone to _not_ have a given same-*
  or other-* command be bound in a given mode or
  context.

In Dired, for example, for some actions I want to
have _only_ a key that reuses the same window.  For
other actions I want to have _only_ a key that uses
another window - or another frame.  And for still
other actions I want to have keys for _both_, or
all 3, possibilities.

To me, it would be a step backward to treat any of
this stuff in some one-size-fits-all, blanket way:
either by automatically creating other-* commands
for everything, or by automatically creating
bindings for them.

Or by automatically creating the equivalent:
providing keys everywhere, for everything, that
provide other-* behavior without creating other-*
commands.  I want only keys that I or some mode
or other context has decided are the most useful
for that particular context.

I have no problem with the supposed "cluttering
[of] the function symbol namespace" from the
existence of separate other-* commands.

(Perhaps that's partly because I use a completion
framework that isn't bothered by the existence of
two commands `foo' and `foo-other-window' etc.)

To me, this "project" of replacing `C-x 4' by a
command is an anti-feature.  (Same for other
prefix keys.)

And again, though I've asked several times now,
I've seen _no_ description of anything useful that
this project aims to provide.  So far, it seems
only like a thought-to-be-clever solution that's
still looking for a problem to solve.

If the problem is _really_ only "cluttering [of]
the function symbol namespace", then that, to me
(just one user) is 100% a non-problem.

And IMO it's certainly not worth tossing out the
beautiful baby of simple prefix-key bindings to
keymaps with the supposedly too-cluttered-namespace
bathwater.

IMO, that bathwater itself is in fact clean &
clear.  It's a mountain stream, not dirty suds.

Just one opinion.