When using Service Provider initiated request, when you access the Pega URL first, we generate the RelayState and send it with the SAMLRequest to the IDP. The IDP will then echos it back along with the SAMLResponse to the AssertionConsumerService. The RelayState is generate value and in a database record associated we store the original URL the user requested. The AssertionConsumerSerivce then redirects back to that original URL after it's done processing. (IDP shouldn't have to do anything here)
When using a IDP initiated request, when you access the IDP first, we require a RelayState parameter along with the SAMLResponse. The value should be the URL of the requested resource. For example https://<prpc_host>/prweb/PRAuth/<AuthAlias>. This is important because with the Pega Platform your AuthService record is the access point and part of the relationship created between SP and IDP. Since you can define more than one AuthService record the IDP has to at least use the AuthService URL as the default RelayState for IDP initiated requests.
You should not modify the ACS processing to set the default RelayState when one is not provided. Some IDP's have a way to set default RelayState as part of the relationship configuration, example Okta. Others require the default RelayState to be a parameter in the initial IDP initiated request. For SP initiated request the sent RelayState should be echoed back. You shouldn't have to "force" anyone to do anything...this is part of normal SAML 2.0 and unless you're using some custom developed IDP you shouldn't have a problem with this.
The RelayState also has nothing to do with determining if the SAMLResponse received was initiated from a Request from Pega. That is handled with normal SAML attributes like "inResponseTo".