SAML doesn't address this specifically because there's really nothing to support at that layer; it's really a matter for the SP and application to address by ensuring that crossing such a boundary results in a second request to the IdP. The main concern is really state. If the application's state is maintained separately from the SAML implementation, then simply re-invoking the SAML authenticaton step with different request content may be sufficient.
Advice to SP Deployers
The specific practices to follow depend largely on the use case for assurance that one has. We are collecting material on use cases identified by the community as valuable.
A concrete piece of advice across all use cases is to document as extensively as possible what your service's requirements, assumptions, and expectations are with regard to assurance so that IdPs can evaluate their systems, and understand the errors that their users might be experiencing. One would expect in the short run that most assurance-requiring services are going to involve some degree of setup and testing, so this documentation will be critical. Think of it as akin to the material used to define attribute requirements for users.