docs PR for arangodb/arangodb#14480

Author: jsteemann

3.9/aql/extending-conventions.md

@@ -37,7 +37,7 @@ purely functional and thus free of side effects and state, and state modificatio
 
 {% hint 'warning' %}
 Modification of global variables is unsupported, as is reading or changing
-the data of any collection from inside an AQL user function.
+the data of any collection or running queries from inside an AQL user function.
 {% endhint %}
 
 User function code is late-bound, and may thus not rely on any variables

3.9/aql/extending.md

@@ -59,6 +59,10 @@ To overcome these mentioned limitations, you may want to increase the
 (at the expense of increased memory usage), and the
 [number of available server threads](../programs-arangod-server.html#server-threads).
 
+In addition, modification of global JavaScript variables from inside UDFs is 
+unsupported, as is reading or changing the data of any collection or running queries
+from inside an AQL user function.
+
 ### Deployment Details
 
 Internally, UDFs are stored in a system collection named `_aqlfunctions`

3.9/aql/fundamentals-limitations.md

@@ -10,6 +10,8 @@ The following limitations are known for AQL queries:
 - An AQL query cannot use more than _1000_ result registers.
   One result register is needed for every named query variable and for
   internal/anonymous query variables.
+- An AQL query cannot have more than _4000_ execution nodes in its initial 
+  query execution plan.
 - An AQL query cannot use more than _2048_ collections/shards.
 - It is not possible to use a collection in a read operation after
   it was used for a write operation in the same AQL query.
@@ -18,6 +20,9 @@ The following limitations are known for AQL queries:
   [`DOCUMENT()` function](functions-miscellaneous.html#document) or
   [traversals working with collection sets](graphs-traversals.html#working-with-collection-sets)
   (instead of named graphs).
+- Expressions in AQL queries cannot have a nesting of more than 1000 
+  levels. For example, the expression `1 + 2 + 3 + 4`, which
+  is 3 levels deep (because it is executed as `1 + (2 + (3 + 4))`).
 - Subqueries that are used inside expressions are pulled out of these
   expressions and executed beforehand. That means that subqueries do not
   participate in lazy evaluation of operands, for example in the