1) /core-service=server-environment:read-resource(<TAB>
==> list of arguments proposed and the "!" operator (because there are some boolean arguments that one could negates).
2) /core-service=server-environment:read-resource(include-r<TAB>
==> include-runtime is inlined.
3) /core-service=server-environment:read-resource(include-runtime<TAB>
==> ")", "," and "=false" are proposed. It makes it clear that providing =true is not required and implicit. The user can choose to type ',' or ')'. If he selects "=" he expects "=false" to be inlined,
4) /core-service=server-environment:read-resource(include-runtime=<TAB>
==> "=false" is inlined as expected.

Now let's use the '!' operator, this time we have:
1) /core-service=server-environment:read-resource(<TAB>
==> propose args and "!"
2) /core-service=server-environment:read-resource(!<TAB>
==> all boolean arguments.
3) /core-service=server-environment:read-resource(!include-r<TAB>
==> include-runtime is inlined.
4) /core-service=server-environment:read-resource(!include-runtime<TAB>
==> only "," and ")" are proposed, the value has been negated, no need for =false.

These 2 scenarios are coherent.

For the write-attribute case, the operation is a meta operation. Proposing true and false makes sense in this case. The user expects to set a value, not to rely on the optimisation (value argument without a value meaning true).