bug#31807: 27.0; `info-apropos' bad name or bad matching

[Drew Adams]

> > If you want to rename `info-apropos' here to `info-apropos-regexp',
> > do so.
> 
> I've instead made info-apropos take a prefix argument to use a regexp
> in Emacs 29.

IOW, _won't_ fix.  Please mark the bug that way, then.

As I said:

 What matters is what _Emacs_ means by "apropos", not what
 Info might mean by it, especially not just what some Info
 switch might be called.
 ...
 If you want to keep the current behavior then I'd suggest
 having two different commands AND, for the one that does
 literal string matching, change the name to something that
 does not include "apropos" in the name.

 It's fine with me that any key-bindings (e.g., menu items)
 for the literal-matching command be kept for the (newly
 named) literal-matching command, if you like.  I don't
 insist that that command or its keys be _supplanted_ by
 a real apropos command.

 The point is that (1) we can and should have an
 apropos-matching command (as a replacement or in addition
 to the current literal-matching command - I don't care
 which), and (2) a literal-match command should not be
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 named `...-apropos' (in Emacs).
 ^^^^^^^^^^^^^^^^^^^

`info-apropos' should provide Emacs "apropos" behavior,
which is regexp and keyword matching, not literal string
matching.

It would be fine to have a literal-matching command,
but it should not be called `info-apropos'.

Alternatively (and what I do in info+.el), it's fine to
let a prefix arg to `info-apropos' match literally, i.e.,
override the default "apropos" matching behavior.

It's _not_ fine (by me) to do what you've done, reverse
the suggested (and Info+) behavior for a prefix arg, so
that the command name _by default_ doesn't correspond
to its behavior (name: "apropos", behavior: literal).

Please change the bug status to "won't fix", to honestly
reflect what you've done.  Thx.