Filters MUST be evaluated using the following order of operations, in
order of precedence:
1. Grouping operators
2. Logical operators - where "not" takes precedence over "and",
which takes precedence over "or"
3. Attribute operators

It should say:

Filters MUST be evaluated using the following order of operations, in
order of precedence:
1. Grouping operators
2. Attribute operators
3. Logical operators - where "not" takes precedence over "and",
which takes precedence over "or"

Notes:

It seems that the precedence of logical and attribute precedence is reversed? The filter filter=title sw "M" and userType eq "Employee" is meant to be interpreted as filter=(title sw "M") and (userType eq "Employee").
This is also the "expected" behaviour consistent with most other languages - with the notable exception of unary "or" which in SCIM is disambiguated as it can only apply to a parenthesized filter expression.

Figure 1 contains the ABNF for SCIM filters. The term "logExp" specifies "FILTER" as an option which unintentionally allows recursion. A valFilter should only allow simple sub-attribute expressions and simple logic. Nesting of valuePath (e.g. attr[a eq b and attr[c eq d]]) should not be possible.

Per the details provided on the SCIM website http://www.simplecloud.info/#overview, the endpoint should be /ServiceProviderConfigs. A trailing "s" is missing. The SCIM implementations of major service providers like Facebook, Salesforce, Slack implement /ServiceProviderConfigs

The example figure is incorrect. It should show the actual patch operation request body in the JSON attribute "data" as it would be expressed in its own HTTP request payload. Instead it shows the values of the "operations" attribute. See sec 3.7 definition of "data".

If the user was already a member of this group, no changes should be
made to the resource, and a success response should be returned.
The server responds with either the entire updated Group or no
response body:
HTTP/1.1 204 No Content
Authorization: Bearer h480djs93hd8
ETag: W/"b431af54f0671a2"
Location:
"https://example.com/Groups/acbf3ae7-8463-...-9b4da3f908ce"

It should say:

If the user was already a member of this group, no changes should be
made to the resource, and a success response should be returned.
The server responds with either the entire updated Group or no
response body:
HTTP/1.1 204 No Content
ETag: W/"b431af54f0671a2"

Notes:

The Authorization header is a request header and should not be included in a response.
The Location header is used to redirect a client to a new location or indicate the location of a new resource. Neither is the case here, so the header should be omitted.

Also, it's unclear from the text whether it's valid to respond with 204 No Content if the user was successfully added to the group.