LTI 1.3 interoperability issues

I have been testing different LTI platforms (including ones listed as being certified by 1EdTech) for their support of LTI 1.3 and encountered a few interoperability issues which I wanted to bring to the attention of others in case they are not intended, or so they can correct my misunderstandings.

1. My reading of the OpenID Connect spec is that Authorization Servers must support Authentication requests sent using both HTTP GET and POST methods. However, at least one 1EdTech certified LTI platform only supports one of these methods. Is the 1EdTech Security Framework intending to relax this requirement, or is it just something which is not included in the certification testing? From the perspective of a tool, it would be very helpful for platforms to support both methods so that a tool need not be concerned about which one it has to use for specific connections.
2. The state parameter in Authentication requests is given as only being recommended in the 1EdTech Security Framework, but I have found more than one certified platform which requires this parameter to be both present and non-empty. Which is correct?
3. For JWTs used for message security, the 1EdTech Security Framework says that the aud claim may be a string value if the array only has one value. This special case is not mentioned for JWTs used for securing web services. However, I have come across one certified platform which only accepts a string value for the aud claim with web services, and generates a 500 Server Error when an array is used. Is the intention to allow the special case to apply to all 1EdTech JWTs? Is it really permissible for a system to only accept one format and not both for the aud value? It would, of course, be a lot simpler to remove such areas of choice, but given that they are permitted some additional clarity would be helpful here.
4. I may have missed this information, but I think it would be very helpful to have a simple list of the values which need to be shared out-of-band between platforms and tools. In many cases I found it difficult to discover the values to be shared by platforms, especially the identity value for access token requests (used as the aud claim). In most cases I found that platforms expect this to be the same as the endpoint to which the request is to be sent, but none appeared to be explicit about this. Indeed it could be useful to define a JSON (or other) format for the data to be shared so that systems could provide simpler interfaces to configure the LTI connections.
5. My reading of the 1EdTech Security Framework is that the response to an access token request must contain a scope element which confirms which scopes the token can be used for. However, I have found one certified platform which does not include the scope element in its response. Is this an error in the spec or should this platform not have been certified?

Thanks.