ORDER BY usage in subquery (derived table) SQL standard allowed or not MariaDB documentation is mentioning that ORDER BY clause in subqueries (derived table) are never allowed by SQL standards. 

Meaning the SQL query 

SELECT
   field1
 , field2
FROM (
  SELECT
       field1
     , field2
  FROM
   table1
  ORDER BY field2
) alias


is never allowed by SQL standards 


  A "table" (and subquery in the FROM clause too) is - according to the
  SQL standard - an unordered set of rows. Rows in a table (or in a
  subquery in the FROM clause) do not come in any specific order. That's
  why the optimizer can ignore the ORDER BY clause that you have
  specified. In fact, the SQL standard does not even allow the ORDER BY
  clause to appear in this subquery


see source

But when i look into the SQL 92 standard. (i know it's old)

4.9  Tables


  ... 
  ... 
     A table is either a base table, a viewed table, or a derived table.
           A base table is either a persistent base table, a global tempo-
           rary table, a created local temporary table, or a declared local
           temporary table. 
  ... 
  ... 
          A derived table is a table derived directly or indirectly from one
           or more other tables by the evaluation of a &lt;query expression&gt;.
           The values of a derived table are derived from the values of the
           underlying tables when the &lt;query expression&gt; is evaluated.
  ... 
  ... 
  
  The simply underlying tables of derived tables and cursors are
           defined in Subclause 7.9, "&lt;query specification&gt;", Subclause 7.10,
           "&lt;query expression&gt;", and Subclause 13.1, "&lt;declare cursor&gt;". A
           viewed table has no simply underlying tables.


They mention cursors let see what they say about cursors and what they are. 

4.21 Cursors


  ... 
  ... 
  
  A cursor in the open state identifies a table, an ordering of the
           rows of that table, and a position relative to that ordering. If
           the &lt;declare cursor&gt; does not include an &lt;order by clause&gt;, or
           includes an &lt;order by clause&gt; that does not specify the order of
           the rows completely, then the rows of the table have an order that
           is defined only to the extent that the &lt;order by clause&gt; specifies
           an order and is otherwise implementation-dependent.


So they mention here a cursor in open state can be a table is either a base table, a viewed table, or a derived table. if you look how they define what a table is in section 4.9 Tables

If i read this i could be interpreting it as using ORDER BY in derived table (like the SQL query above) is perfect valid by SQL standards and it's up to vendors if they would allow ORDER BY there as a option. 
But i would be interpreting it wrong english is not mine mother laungauge, so the question is iám interpreting it correctly?
A cursor is not a table, it refers to a table or a view of that table.  The cursor has an order only to the extent that the query that defines the cursor has an order by.  A subquery within that larger query would not define the order, and the fact that the query is being used for a cursor doesn’t make an order by in subquery legal syntax.

Basically, as with any other query, if you don’t have an order by on the outermost layer, then the optimizer is free to return the results in what it deems is the easiest/quickest way. It may take advantage of indexes or caches or anything else that allows it to produce the correct result, but is not constrained to do so.