The way OP worded their request could be improved, but what they’re suggesting is reasonable. Based on the API, I’m assuming (I have no internal knowledge of the filter) that there are two types of filtering: outbound and inbound. Below are diagrams A, B, and C (from left to right):
Diagram A is the behavior of regular filtering. The outbound filter protects the sender’s PII/etc depending on how “innocent” they are. The inbound filter protects the receiver from profanity/etc depending on how “innocent” they are.
Diagram B displays the behavior of FilterForBroadcast. Since the receiver can be anyone (e.g. a 7-year-old), it has to use the most restrictive filter to be suitable for all ages. There is a lot of room for words to be filtered undesirably because the filter is so strict. Diagram C displays the behavior the OP is requesting: the ability to remove the inbound filter. Since the place owner would not need to be protected from profanity/etc, we could remove the inbound filter entirely. Depending on how strict/inaccurate it is, this could remove a significant amount of false positives.
Proposed Solution:
I don’t think removing the inbound filter entirely is a good idea. A 10-year-old could make a game and then be exposed to inappropriate content because their feedback system isn’t filtered. Instead of removing the inbound filter entirely (unsafe) or being forced to comply via FilterForBroadcast (tons of false positives), developers should be able to filter from sender → developer. This would decrease the harshess of the inbound filter the older a developer is.
This is currently not possible because the filter methods require player instances for some reason. This could easily be rectified by allowing those arguments to be overloaded with UserIds – I’m not sure why they require player instances to begin with.