That would require more just than a customization point. It would need a separate associated type as the return value. Currently filter returns [Element] (unless you're a range-replaceable collection).
Such a return type was proposed in SE-0174 but never implemented, because at the time it required recursive constraints (the filtered return type should be constrained to the same point in the protocol, similar to how SubSequence or Indices is). This was back in the days before proposals needed implementations.
Despite being the author of that proposal, I now feel like it would be a mistake to do this based on later experience. But if we wanted to do it at some point in the future, removing the customization point now would actually be a big step towards that, because we wouldn't then have the situation of needing to keep the old customization point and having it interact oddly with the new one with a different return type on the same protocol.