bug#60942: 30.0.50; [PATCH] Indices in Eshell variable interpolation don't work with async subcommands

[Eli Zaretskii <eliz@gnu.org>]

> Date: Wed, 18 Jan 2023 19:36:41 -0800
> From: Jim Porter <jporterbugs@gmail.com>
> 
> Starting from "emacs -Q -f eshell":
> 
>    ~ $ echo $exec-path[0]
>    /usr/local/sbin
>    ~ $ echo $exec-path[${echo 0}]
>    /usr/local/sbin
>    ~ $ echo $exec-path[${*echo 0}]
>    ;; no output
> 
> This is because 'eshell-eval-indices' gets an S-expr describing code to 
> evaluate for the indices, and it just passes that to 'eval'. That's not 
> the right way to do things for Eshell: instead, we should rely on 
> 'eshell-do-eval', which properly handles asynchronous evaluation. That's 
> required for working with external commands like "*echo" (which calls 
> the real /bin/echo).
> 
> The attached patch fixes this by changing 'eshell-eval-indices' to 
> 'eshell-indices', which does some minimal transformations on the S-expr 
> for the indices, and then uses it to build the final S-expr to pass to 
> 'eshell-do-eval'.
> 
> This could possibly go in Emacs 29, since it's a bugfix to add onto a 
> previous bugfix (see commit 990f36fa10). However, I'd lean towards just 
> merging to master; this is a fairly obscure issue, and we can't just fix 
> *every* bug we find on the release branch, or the branch will never 
> stabilize. If someone else thinks it's important enough to go on the 
> release branch though, I won't argue.

Why do you remove a non-internal function?  We cannot possibly do that
if this is going to be installed on the emacs-29 branch.  But even if
you are going to install on master, why not leave that function alone?
Some code somewhere could be using it, and we don't usually remove
functions before a period of deprecation.