Based on your concerns, you may be a little confused about how an Adaptor component fits into an architecture.
The different solution providers provide different set of interfaces and functionality behind them. No one can guarantee that the interfaces added for the first provider will be supported later by another one.
The point of an adaptor is not being able to switch from one provider to another without changing the adaptor implementation. The goal is to create an interface used by your adaptor's clients that doesn't change unless requirements change. The idea is to minimize the impact of such changes on the larger architecture. The adaptor's implementation (not its interface) should be expected to need to change, otherwise it has little purpose.
The fact that different providers might have different APIs is the main reason to implement an adaptor, not a contra-indication.
On other hand, no one can guarantee that the interfaces which were added for the first solution provider to fulfil needs of one project will be demanded by other projects.
If an alternate 3rd-party provider cannot support your requirements, why would you use that provider? The requirements should drive the solution. Changing your requirements based on what a 3rd-party provides is (IMO) a backwards way to think about solution design.
In fact, building an adaptor can help you determine if a given 3rd-party solution meets your requirements. Once you have built an adaptor whose interface is specific to your requirements, i.e., it provides the necessary operations and nothing more, evaluating a 3rd-party's solution becomes an exercise simply determining whether you can implement your adapter against that 3rd-party. If you can't, it doesn't support your requirements.
Simply the signature of each interface can be different from provider to provider.
This is the main reason why adapters are introduced. If you could guarantee they provider interfaces will always be the same, then the case for building an adaptor layer is much weaker.
In a nutshell, all these are reasons you would potentially create an adaptor layer/component, but you seem to think they are reasons not to do it. As to whether you should do this, that's a harder question. As an analogy, let's say you need to make a workbench. You could create a standard workbench where everything is permanently glued together, or with more effort and planning you could create a 'knock-down' workbench which can be easily disassembled and moved. Which should you build? The answer is that if you don't ever need to disassemble it, you probably shouldn't bother with the extra work. But if you do find you need to move it often, you'll might be better off (in the long-run) making the knock-down bench.
It can be very difficult to make such predictions and it's probably not something you want to do in a vacuum. If it's clear that there is a desire to be able to change providers with minimal switching-costs, that might be enough reason to do this alone, even if you never actually change providers. The reason is that a credible threat of leaving one provider can be an advantage in negotiations. If the provider knows moving to another will come at a high cost to your organization, they don't need to try as hard to keep your business. It's also my experience that 3rd-parties will change their implementations drastically over time.
If you decide to build an adaptor, be careful about duplicating the APIs and features of your first provider. Specifically: only implement the features you actually use on your API. I would even try to ignore the design of the 3rd-party's APIs, at least initially. Your goal is to create an API designed around your organization's needs, not the 3rd-party's.
