> If the messages are just printed in the message buffer it shouldn't
> impact too much the startup time I think.
To do the kind of analysis you are talking about, one would have to
hook into really basic subroutines like `setq`. I don't have any
numbers to back this up, but that sounds like it would be a massive
slowdown for all Elisp code. Alternatively, you'd have to do a lot of
heavy static analysis because what defines a "outdated, deprecated, or
useless" setting is actually quite nebulous and complicated.
I do actually think this is an interesting idea, but it would
definitely best be implemented as either a third-party package or some
optional user library in core that either does static analysis or
allows one to load the init-file with profiling enabled like ESUP [1]
(or both).
> a number of people find even an extra 0.5s-1.0s in startup to be
> significant
I am one of those people, and actually I find even an extra 50ms of
startup time to be unacceptable unless there's a good reason for it.
My ~5,000 line configuration [2] which pulls in ~130 packages takes
only ~250ms to load, according to a startup profiler -- meaning 0.6s
to go from nothing to a full graphical frame.
Why bother with the Emacs server when you can just make Emacs start up
as fast as Vim? ;)