Consider the following query.
import schema namespace s = "http://www.w3.org/XQueryTest/RequireProhibitF
eature";
declare function local:foo() as schema-element(s:foo)
{
...
}
declare option prohibit-feature "schema-aware";
local:foo()
It is not until we are well into parsing that the option prohibiting use of import schema is encountered. This is quite annoying.
Consider also a processor which has schema awareness disabled by default.
import schema namespace s = "http://www.w3.org/XQueryTest/RequireProhibitF
eature";
declare function local:foo() as schema-element(s:foo)
{
...
}
declare option require-feature "schema-aware";
local:foo()
It is not until we are well into parsing that the option enabling use of import schema is encountered. This is similarly annoying.

Another example of the same effect occurs when the higherOrderFunction feature is disabled after a function or variable declaration that makes use of it.
However, I'm inclined to live with it. In general, we allow forwards references; it's a hassle for implementors, but that's the job that implementors are paid for.

There's also a usability issue. It's natural to write the require/prohibit before the feature is used - but this is grammatically incorrect.
Other examples include use of validate expressions in a function, or use of fn:serialize with serialization disabled.
That means it's awkward for every XQuery 3.0-defined feature except static typing.

Additionally, I don't find this construct particularly intuitive.
Without a detailed reading of the specification, I'd expect:
declare option prohibit-feature "higher-order-function";
declare option require-feature "all-optional-features";
either
a) to complain that the higher-order-function feature is both prohibited and required (since higher-order-function is in the set of all optional features), OR
b) to disable the higher-order-function feature and then re-enable it.