> The BNF for CREATE PROCEDURE/FUNCTION is lacking in a couple areas.

Do you mean the BNF or the rail road diagram above and associated text? We do have an issue with the diagrams in that they are not automatically generated, so only the BNF page is guaranteed to be accurate.

> 1) Need more examples representing the various combinations of statement options

Do you mean the body definition statement or the whole declaration?

> 2) Not sure how users should use parameter DIRECTIONs (IN/OUT/INOUT) versus RESULT when defining a procedure that returns a single datatype'd variable?
> 3) Missing info on what might happen at deployment/run-time if a there are conflicting OUT/RESULT values AND a defined RETURNS TABLE (.....) added? (i.e if both defined who wins, or will deployment fail?

There is some overlap in the metadata here as the syntax is representing both procedures and functions.

There can only be a single RESULT parameter and it must be an out. It is the same as having a single non-table RETURNS type. They are expected to match if both are declared. "RETURNS type" is shorter hand syntax especially for functions, while the parameter form is useful for additional metadata (explicit name, extension metadata etc.)