I don't normally set user-emacs-directory via --eval argument. Instead
it is set within a file which is loaded via --eval. I suppose this is
not that significant difference. In the original report I tried to
remove all non-essential stuff by coming up with a minimum instruction
that demonstrated the problem. Isn't that how you would like most
problems reported?
For the first 25 or so years, I used ~/.emacs to customize emacs.
However for the past few years I switched to using "eamacs -q --eval ...
--eval ... " style. This decision was not because of my ignorance of
other command line options that emacs provides. Instead this style gave
me the flexibility to generate elisp on the fly to setup emacs exactly
the way I want without having to edit any files. I happen to use python
script that takes few command line arguments, which then may generate
elisp files, and/or generate appropriate --eval arguments. The primary
motivation for this style of emacs launching is to allow me to enable or
disable spacemacs, enable or disable my own configration, etc. This
flexibility is very handy when something goes wrong. I can quickly
eliminate big parts of potential causes.
With packaging system, there are so many useful packages that I want to
use. Unfortunately stability suffers. I did not know about "kill -USR2
<pid>" until recently as some have also pointed out in emacs-devel list.
So ability to diagnose problems quickly is important to me.
The reason I test drove emacs 26 was in response to a call for testing
concurrency stuff. Until this I used only emacs-25 git branch for months
and months. The problem I reported is not a big deal for me. I can
easily suppress the warning by doing something like
cd
rm -rf ~/.emacs.d
mkdir ~/elisp/.emacs.d
ln -s ~/elisp/.emacs.d
so that if emacs were to create a file under ~/.emacs.d, then I would
know about it since ~/elisp would be version controlled via git.
reasons for not doing that.