IMHO its standard that unknown URL parameters are simply ignored. I
think we should not change this principle.

It's usually the right thing to do to be open to future backward-compatible changes, but I don't know of any such standard, as it equally makes future non-backward-compatible changes impossible.

Whatever will be defined in the BIP is the standard in this case.

> (For example, if something that restricts the validity, such
> as "expires" is added later on, it is pretty important not to ignore it.
> Older clients should refuse to comply.)

In this case, you'd need to refuse *all* parameters you don't know
about. In consequence, all extensions would break older clients.

Which is exactly what I want to avoid by defining this up-front.

A versioning scheme can avoid this. Any BIP that breaks backwards compatibility (for example, adds a multiple-send type or specific restriction) should increase the version number. A client rejects URLs with a version number higher than what it knows about.

That's the simplest way to handle it, and enough IMO.

Wladimir