>> * These should probably be consistent.
>> * I think returning a quark is dangerous in case of sloppy package
>> authors.

From the seq point of view, I like the idea of \seq_pop:NNF, with a
\seq_pop:NN variant for an expl3-provided error.

For prop, a missing key is more often not an error(?), so perhaps
providing all four \prop_get:NnN(T)(F) variants may make sense. They
would be implemented internally with a quark test on the result of
\prop_get:NnN (very small performance overhead). Then
\prop_if_in:Nn(TF) would be much less useful, since it is just as slow
as \prop_get:NnN(T)(F).

> I find that the quark-based approach is about twice as fast as using
> \prop_if_in:Nn.

Yes, you end up doing the same work (defining an auxiliary function,
expanding the prop, grabbing delimited arguments) twice. And quark
tests on single tokens are fast.

In these kind of cases, I feel like providing an optimized function in
the kernel is better than letting higher-level programmers try to
guess what is the right/fastest way of doing things.