Original text:
IANA.well-known.  Examples of this construction can be found in PRConfigurationRequest.  Different applications utilizing OAuth protected resources in application-specific ways MAY define and register different well- known URI path suffixes for publishing protected resource metadata

Reviewer comments:
Cc NAME
well that's one way to solve it!
URL Change "applications" to "deployment" for clarity
Looking at making the change, there are ~12 places we'd be changing "application" to "deployment" and it's not clear that it would improve the readability or clarity of the text. Furthermore, I'll also point out that this is the language used in RFC 8414, and it seems to have worked for people there, so I'm reluctant to make this change, given I don't think it would be a significant enough improvement to warrant being different. cc NAME
My comment about this section was that it was generally quite hard to follow, not that "application" should be replaced by "deployment". This sentence took a while to parse: "Different applications utilizing OAuth protected resources in application-specific ways may define and register different well-known URI path suffixes used to publish protected resource metadata as used by those applications. " I think the intent here is to say that an application may be composed of different OAuth protected resources, and each of those may have their own protected resource metadata, and if this is the case, your describing a scheme on how the application may expose the resource metadata to clients for each of the underlying OAuth protected resources. If that is the intent, changing from "application" to "deployment" may not help (these are different concepts). Perhaps just an introductory sentence for that paragraph - something like: "An application may access multiple OAuth protected resources in order to complete an operation. Each OAuth protected resource may have their own resource metadata. In this case, the application may define and register different well-known URI path suffixes used to publish protected resource metadata as used by those applications to enable a client to obtain the resource metadata for each of the underlying resources. As I write this, I think my confusion here was more about the lack of clarity on the relationship of the application (which may itself be an OAuth protected resource?) and the OAuth protected resources (which it relies on to perform an action).
NAME talked about this in Rome. The term "application", as used, encompasses all the components used to accomplish the task for the use case. That can include OAuth clients, authorization servers, and protected resources, inclusive of the code running in each of them. Applications are built to solve particular problems and may utilize many components and services. I could add an introductory remark derived from the above, if that would work for you. (Although I would try to make it more concise.)
Looks good to me.

Revised text:
IANA.well-known.  Examples of this construction can be found in PRConfigurationRequest. <ins> The term "application", as used below (and as used in RFC8414), encompasses all the components used to accomplish the task for the use case.  That can include OAuth clients, authorization servers, protected resources, and non-OAuth components, inclusive of the code running in each of them.  Applications are built to solve particular problems and may utilize many components and services. </ins> Different applications utilizing OAuth protected resources in application-specific ways MAY define and register different well- known URI path suffixes for publishing protected resource metadata