So this means if our native library use a third-party lib A, in order to make it work for Xamarin, we will HAVE to make sure Xamarin actually supports lib A as well. Otherwise we might have to create another binding for lib A. In other words, if we go down this road, we HAVE to always think about what is supported by Xamarin when we make changes to our native SDK. Is that right?

Basically. The big ones are firebase (for push) and the support libs (for literally everything). Xamarin has versions of those that it maintains, but they are often a few releases behind Android. If our SDK uses a newer version our options will be to either bind it ourselves (which is non trivial, but out of scope for this comment) or Xamarin uses an older SDK (or fork thereof).

Why do we need to make changes in Xamarin? Is there much code in the binding project? I thought all the changes just need to be made in the native libs, and then maybe update the binding project to reflect the changes?

There isn't much "code" in the binding project. Xamarin maps the native APIs into a .Net styled name space and we just have to add some naming information. We do this twice, once for android and once for iOS and then those projects wrap the code in the interfaces Xamarin expects to see. If we need Xamarin specific features ( I believe that Xamarin.Forms has a niceties that want data in a specific format) then that means we need to implement those at least three times (once in the Xamarin interface the bindings link to and once in each of the bindings classes) and possibly five times if it requires changes to the native SDKs.