Oops, you're right about unfulfilled cond-expand - R7RS states if no conditional is satisfied and there's no else clause, the behavior is unspecified.
But it is also undefined how import behaves when the specified library doesn't exist.  So on the ground of the specifications, there's not clear preference in the current state.

My point is that import is about namespaces, while cond-expand is about checking features.  If you want to check features, better to use the features actually intended for that purpose.
To improve the current status, I'd suggest to make it explicit that cond-expand notifies the user about unfulfilled feature conditionals, rather than overloading import for different purpose.


On Wed, Mar 28, 2018 at 9:05 AM, Ciprian Dorin Craciun <xxxxxx@gmail.com> wrote:
On Wed, Mar 28, 2018 at 8:34 PM, John Cowan <xxxxxx@ccil.org> wrote:
>> Wait, I was wrong.  The canonical way should be
>> (cond-expand (srfi-N))
>
>
> SRFI 0 cond-expand doesn't assume the same set of primitive features as R7RS
> cond-expand.  In particular, (library (srfi N)) is the right way on R7RS.


:)  My point on allowing a simple `(import (srfi 62))` and be done with it...


On Wed, Mar 28, 2018 at 8:13 PM, Shiro Kawai <xxxxxx@gmail.com> wrote:
> Note that cond-expand throws an error if the feature requirement is not
> satisfied, so if you don't need to customize the error message,
> (cond-expand ((library (srfi N)))) should suffice the purpose.


It seems that just a simple `(cond-expand ((library (srfi 62))))`
doesn't throw any error at least in Chibi (it just expands into `#t`).
(In Gauche it does give an error.)

Therefore the only "portable" (as in "sure") way is to explicitly
check for `not condition` and throw an error.  :)

Ciprian.