Problem:  gui.color_approx in gui_T has not been assigned anywhere since
          patch 7.4.2094 ("The color allocation in X11 is overly
          complicated", 2016), which dropped the single "gui.color_approx = TRUE;"
          site.  Because the member is zero-initialized and never written, the
          check "if (gui.color_approx)" in gui_mch_init() is always false and the
          "E458: Cannot allocate colormap entry, ..." warning can never be
          emitted.
Solution: Remove the struct member and the unreachable branch.  The E458
          error definition is removed. Update the example error code
          "E458" in the ex_eval.c comment to "E457" accordingly.

closes: vim/vim#20007

https://github.com/vim/vim/commit/fe3c27ce0b7b889a2ae29833cae55ca92ae86518

Co-authored-by: Hirohito Higashi <h.east.727@gmail.com>

Problem:    Informational message has an error message number.
Solution:   Use a message without an error number. (closes vim/vim#11530)

https://github.com/vim/vim/commit/b53a190e9f8a767bbd4be2f538649a09f9c8ba4b

Co-authored-by: Bram Moolenaar <Bram@vim.org>

Problem:  Deeply nested regexp groups can cause uncontrolled recursion
          in the regexp compiler and exhaust the C stack.
Solution: Limit recursive regexp parsing depth in both the backtracking
          and NFA compilers (lipengyu)

closes: vim/vim#20731

https://github.com/vim/vim/commit/a79cd6bfc3e85e1d9f1ec48eda76c7385b44bf69

Co-authored-by: lipengyu <lipengyu@kylinos.cn>

Problem:
Not easy for one UI to kick the others off a shared Nvim server.

Solution:
Treat `:%detach` as detach-other-UIs.

* refactor(autocmd): safely parse buflocal buffer numbers

Replace unsafe atoi with a robust integer conversion when extracting
the buffer number out of a "<buffer=123>" pattern in
aupat\_get\_buflocal\_nr.

This prevents potential silent integer overflows and ensures variables
fit safely within INT\_MAX boundaries before truncation.

* fix(autocmd): use getdigits_int to safely parse buffer numbers

* fix(autocmd): raise error for invalid buffer-local pattern values

When defining an autocommand, an invalid buffer-local pattern format
(such as `<buffer=foo>` or `<buffer=0>`) would previously fall through
silently and default to a generic `<buffer>` tag behavior.

Fix this regression by trapping invalid buffer numbers
early from `aupat_get_buflocal_nr()` and throwing a proper E680 error
to match Vim's runtime validation behavior.

Problem:  spell: a word in a .dic file with many postponed prefix or
          compound flags overflows the fixed-size store_afflist[MAXWLEN]
          buffer in get_pfxlist() and get_compflags().
Solution: Add bounds checks (Yasuhiro Matsumoto).

closes: vim/vim#20286

https://github.com/vim/vim/commit/9a920e82546dace49a0a88dced80d29a39efbdb0

Co-authored-by: Yasuhiro Matsumoto <mattn.jp@gmail.com>

Problem:  Crash with invalid shellredir/shellpipe value
          (bfredl)
Solution: Validate the option and allow only a single "%s".

fixes:  vim/vim#20157
closes: vim/vim#20159

https://github.com/vim/vim/commit/84ae09dd79b9888ba71dc2a28f9afcac3e7b8901

Co-authored-by: Christian Brabandt <cb@256bit.org>