1. any reason for why we use both emplace_back and push_back in the implementations of these 2 methods or could we use just one of them instead?
2. Not entirely sure how is addPlatformFilter supported to work given that it does take only 1 argument as opposed to its Swift and Kotlin counterparts that take 2. I realize that we discussed this briefly in our last community meeting but I thought that we would not add addPlatformFilter method at all.

1. emplace_back is used because we are constructing a new NativeFilterConfig object which we don't have yet, so the arguments to emplace_back are the arguments to the NativeFilterConfig constructor. I could do push_back(NativeFilterConfig(name, typed_config)) but that would be slightly more verbose. I

The abseil advice (https://abseil.io/tips/112) boils down to:
So in general, if both push_back() and emplace_back() would work with the same arguments, you should prefer push_back(), and likewise for insert() vs. emplace().

2. this implementation of addPlatformFilter simply adds the platform filter name to the envoy config. It does not, however, register the PlatformFilter into the Envoy API. The Swift and Kotlin builders do both of those things. Once the Kotllin and Swift builder call into the C++ builder, they will still do the language specific Filter registration, but they will need the C++ builder to configure Envoy to use it. I hope that helps!

this implementation of addPlatformFilter simply adds the platform filter name to the envoy config. It does not, however, register the PlatformFilter into the Envoy API. The Swift and Kotlin builders do both of those things. Once the Kotllin and Swift builder call into the C++ builder, they will still do the language specific Filter registration, but they will need the C++ builder to configure Envoy to use it. I hope that helps!

That does definitely help and makes sense! Maybe it would be a good idea to drop some comment with regard to that in addPlatformFilter method's implementation? leaving the decision up to you.