In items #91, #148 and #150 we voted to allow the use of include, include-ci and cond-expand at the "top-level" respectively, but there remains some confusion as to their semantics.
Here "top-level" refers to repl and program body top-levels, but not library bodies.
One interpretation is that these behave like library declarations, and can expand into import forms. In this case, for a purely static implementation of R7RS libraries, they must first be statically scanned from all top-level forms. They cannot be used outside the top-level, and are not even available as bindings otherwise. This is the declaration proposal.
Another interpretation is that they are just normal macros with the obvious definitions (cond-expand in terms of the output of the features procedure), are available in the (scheme base) library, and consequently can't be used to expand into import since imports have already been resolved. This is the syntax proposal.
Alternately, we could provide both. If you think this is all too confusing you could also vote remove, to drop these extensions.
Related is the matter of whether multiple import forms are allowed in programs or only one may allowed as in R6RS. With either syntax or remove it could make sense to add this restriction, so the /single-import variant is provided. Note the repl allows allows multiple import forms.
WG1 voted to accept the syntax alternative. As a result, include, include-ci, and cond-expand become normal syntax keywords in the (scheme base) library as well as being library declarations. They are no longer special either at the REPL or in top-level programs.
At least the first two cannot be expressed as syntax-rules macros using only portable procedures, and so must be described as new primitive expression types in Section 4.1.