>     - `assoc?` -- (cadr (assoc key alist)) or #f if not found
>
> This does not follow the naming pattern used in the R7RS.

True, but how would you follow it? :) assoc-ref or alist-ref is nice,
but it doesn't generalize naturally to the regexp operators ? + *.

>     - `assoc1` -- (cadr (assoc key alist)) or raise exception if not found
>
> Which exception is raised? There is no point in raising an exception
> when it cannot be inspected.

I've used them ad hoc so I didn't care about that. A SRFI on the topic
should specify some kind of not-found exception like Python's KeyError.

>     There's also the further question of whether these should check the
>     entire list for duplicate keys or not.
>
> This would the already low efficiency of association lists even lower.

But decreases the chance of error.

> Using two-element lists instead of pairs means that another pair has to
> be needlessly allocated for each entry in the association list.

For efficiency, use vectors or hash-tables :)

Is CDR coding (implicitly storing the linked list in tag bits) still in use?

> SRFI 1 has `alist-cons' and through this already sets a standard, namely
> pairs instead of lists for associations.

Neat. I didn't realize it has alist stuff:

- assoc
- assq
- assv
- alist-cons
- alist-copy
- alist-delete
- alist-delete!

alist-delete walks the entire list and deletes all matching keys.

alist-cons doesn't replace the value of an existing key. That's logical
given its name, but perhaps not intuitive.