Agreed, you have to be careful when choosing something which will be wrapped around in a large portion of the engine, however, just to be on the safe side, i'd recommend creating a 'wrapper' library which sits between the main code, and the engine you use. That way, if at some point you change your mind, just re-implement your custom (classes/)methods.
Also means that if an update to the physics engine does become avaliable and changes something, you can transparently alter your wrapper.
I did this recently with a small C++ linux project i was working on, given the different OSs, the socket engine varied (i could have stuck with the basics, but Linux 2.6+ and FreeBSD have optimised socket engines). During the configuration stage, a single include is added for the socket engine it's going to use, and it becomes built in with no changes to the core code
Something to concider.