Problem:    Items in a list given to :const can still be modified.
Solution:   Work like ":lockvar! name" but don't lock referenced items.
            Make locking a blob work.
https://github.com/vim/vim/commit/021bda56710d98c09a6b35610a476ab2dd8c58ad

Problem:    Cannot use octal numbers in scriptversion 4.
Solution:   Add the "0o" notation. (Ken Takata, closes vim/vim#5304)
https://github.com/vim/vim/commit/c17e66c5c0acd5038f1eb3d7b3049b64bb6ea30b

:scriptversion is N/A.

Cherry-pick latest str2nr() doc changes from v8.1.2035.
Cherry-pick various mentions of the 0o prefix from:
 - v8.2.2324
 - https://github.com/vim/vim/commit/2346a6378483c9871016f9fc821ec5cbea638f13
 - https://github.com/vim/vim/commit/11e3c5ba820325b69cb56f70e13c21d7b8808d33
 - https://github.com/vim/vim/commit/82be4849eed0b8fbee45bc8da99b685ec89af59a

Patch used ascii_isbdigit() by mistake, which was fixed in v8.2.2309.

Make STR2NR_OOCT work the same as STR2NR_OCT when forcing.
In Vim, STR2NR_FORCE | STR2NR_OOCT isn't handled, and doesn't actually
force anything. Rather than abort(), make it work as STR2NR_OCT.

This means STR2NR_FORCE | STR2NR_OCT works the same as
STR2NR_FORCE | STR2NR_OOCT and STR2NR_FORCE | STR2NR_OCT | STR2NR_OOCT.

Problem:    The str2nr() tests fail.
Solution:   Add missing part of patch.
https://github.com/vim/vim/commit/1ac90b4fa63414d56750559506a3e076df6923b0

Add extra tests for quoted numbers in vim_str2nr_spec.lua, as the
included ones in this patch are somewhat lacking.

Problem:    Obvious mistakes are accepted as valid expressions.
Solution:   Be more strict about parsing numbers. (Yasuhiro Matsumoto,
            closes vim/vim#3981)
https://github.com/vim/vim/commit/16e9b85113e0b354ece1cb4f5fcc7866850f3685

Update vim_str2nr_spec.lua to add more tests that use strict = true.

Revert "tests: unit: fix preprocess: pass -m32 for 32bit ABI (#11073)"

This reverts commit ed11721b6bb36042ab065b5045c8eb01115b8902.

It broke multiple 32-bit builds and isn't actually required for building
in a true x86 32-bit environment.

Remove syncolor.vim in favor of defining the default highlight groups
directly in `init_highlight`. This approach provides a number of
advantages:

1. The highlights are always defined, regardless of whether or not the
   syntax regex engine is enabled.
2. Redundant sourcing of syntax files is eliminated (syncolor.vim was
   often sourced multiple times based on how the user's colorscheme file
   was written).
3. The syntax highlighting regex engine and the highlight groups
   themselves are more fully decoupled.
4. Removal of the confusing `:syntax on` / `:syntax enable` dichotomy
   (they now both do the same thing).

This approach also correctly solves a number of bugs related to
highlighting (#15176, #12573, #15205).

Problem:    Can modify a:000 when using a reference.
Solution:   Make check for locked variable stricter. (Ozaki Kiichi,
            closes vim/vim#3930)
https://github.com/vim/vim/commit/05c00c038bc16e862e17f9e5c8d5a72af6cf7788

As per #14236, performing extmark cleanup in a certain namespace does
not guarantee removing all the extmarks inside given namespace.
The issue resides within the tree node removal method and results in
a couple of rare edge cases.

To demonstrate what causes this bug, I'll give an example covering one
of the edge cases.

=== AN EXAMPLE ===

   (A)         (B)         (C)         (D)         (E)
---------   ---------   ---------   ---------   ---------
  <0, 1>      <0, 1>      <0, 1>      <0, 1>      <0, 1>
  <0, 2>      <0, 2>      <0, 2>      <0, 2>      <0, 2>
  <0, 3>      <0, 3>      <0, 3>      <0, 3>      <0, 3>
  <0, 4>      <0, 4>      <0, 4>      <0, 4>      <0, 4>
  <0, 5>      <0, 5>      <0, 5>      <0, 5>      <0, 5>
  <0, 6>      <0, 6>      <0, 6>      <0, 6>      <0, 6>
  <0, 7>      <0, 7>      <0, 7>      <0, 7>      <0, 7>
  <0, 8>      <0, 8>      <0, 8>      <0, 8>      <0, 8>
  <0, 9>      <0, 9> *           *    <0, 9>  *   <0, 9>
[0, 10] *   [0, 10]     <0, 9>        [0, 11]     [0, 11]
  [0, 11]     [0, 11]     [0, 11]     [0, 12]     [0, 12]  *
  [0, 12]     [0, 12]     [0, 12]     [0, 13]     [0, 13]
  [0, 13]     [0, 13]     [0, 13]     [0, 14]     [0, 14]
  [0, 14]     [0, 14]     [0, 14]     [0, 15]     [0, 15]
  [0, 15]     [0, 15]     [0, 15]     [0, 16]     [0, 16]
  [0, 16]     [0, 16]     [0, 16]     [0, 17]     [0, 17]
  [0, 17]     [0, 17]     [0, 17]     [0, 18]     [0, 18]
  [0, 18]     [0, 18]     [0, 18]     [0, 19]     [0, 19]
  [0, 19]     [0, 19]     [0, 19]   [0, 20]     [0, 20]
[0, 20]     [0, 20]     [0, 20]

DIAGRAM EXPLANATION

* Every column is a state of the marktree at a certain stage.

* To make it simple, I don't draw the whole tree. What you see are
   2 leftmost parent nodes ([0, 10], [0, 20]) and their children placed
   in order `MarkTreeIter` would iterate through. From top to bottom.

* Numbers on this diagram represent extmark coordinates. Relative
   positioning and actual mark IDs used by the marktree are avoided
   for simplicity.

* 2 types of brackets around coordinates represent 2 different
   extmark namespaces (`ns_id`s).

* '*' shows iterator position.

ACTUAL EXPLANATION

Let's assume, we have two sets of extmarks from 2 different plugins:
  * Plugin1: <0, 1-9>
  * Plugin2: [0, 10-20]

1. Plugin2 calls
    `vim.api.nvim_buf_clear_namespace(buf_handle, ns_id, 0, -1)`
    to clear all its extmarks which results in `extmark_clear` call.

2. The iteration process goes on ignoring extmarks with irrelevant
    `ns_id` from Plugin1, until it reaches [0, 10], entering state (A).

3. At the end of cleaning up process, `marktree_del_itr` gets called.
    This function is supposed to remove given node and, if necessary,
    restructure the tree. Also, move the iterator to the next node.
    The bug occurs in this function.

4. The iterator goes backwards to the node's last child, to put it
    in the place of its deleted parent later. (B)

5. The parent node is deleted and replaced with its child node. (C)

6. Since now this node has 8 children, which is less than
    `MT_BRANCH_FACTOR - 1`, it get's merged with the next node. (D)

7. Finally, since at (B) the iterator went backward, it goes forward
    twice, skipping [0, 11] node, causing this extmark to persist,
    causing the bug. (E)

ANALYSIS AND SOLUTION

The algorithm works perfectly when the parent node gets replaced by
its child, but no merging occurs. I.e. the exact same diagram,
but without the (D) stage. If not for (D), it would iterate to <0, 9>
and then to [0, 11]. So, iterating twice makes sense. The actual problem
is in (C) stage, because the iterator index isn't adjusted and still
pointing to no longer existent node. So my solution is to adjust
iterator index after removing the child node.

More info: https://github.com/neovim/neovim/pull/14719