Why does using a lstset option in usepackage command make pdflatex not terminate?

Question

Question

Why does passing a wrong (as in non-existing) option to listings upon package loading result in a non-terminating pdflatex run, instead of - say - a simple error message?

Background

Section 2.2 Package loading of listings.pdf indicates that only the words 0.21, final, draft, savemem (and possibly some undocumented experimental switches) are valid options supported on package loading:

\usepackage[options]{listings}

However, this didn't stop me from happily trying to include a basicstyle=\ttfamily option that should only be set via \lstset.

Strangely enough, this mistake didn't trigger a simple unknown option error, but instead captured pdflatex in an infinite loop with the last log output being:

(C:\miktex-portable\tex\latex\listings\listings.sty
! Missing \endcsname inserted.
<to be read again> 
                   \protect 
l.2235 \lst@RequireAspects
                          \lst@loadaspects
? 

MnWE (minimum not working example)

\documentclass{scrartcl}
%% Ok
%\usepackage{listings}
%\lstset{basicstyle=\ttfamily}

%% NOT Ok
\usepackage[basicstyle=\ttfamily]{listings}

\begin{document}
\lstinline{int k = 0;}
\end{document}

Answer 1

You may have noticed that even packages which sport key-value syntax in the options refrain from allowing control sequences in the values.

This has to do with how LaTeX manages the list of options, in order to zap spaces and divide it into pieces at commas.

Since \ttfamily is a command that's defined as robust with \DeclareRobustCommand, it is not allowed where \zap@space is expected to act on.

Low level errors are to be expected in this case, earlier than the package can issue the “unknown option” warning/error.