I've used Bullet in a professional capacity, and I'd hesitant
to force the GC on your users. I'd port their allocators and
supply implementations that map to malloc or the GC and let
users that have their own heap implementations map them to
those.
There are a couple of reasons for this:
1) Most large game engines/simulations probably already have
several types of custom allocators that they'd like to map
bullet allocations to.
2) GC is not necessarily the best model for keeping track of
physics data. Usually, physics objects are tied to their game
entity counterparts and should be cleaned up as soon as those
go away. This ownership is mostly unambiguous, so its not much
of a burden to remember to clean up the physics objects. I used
ref counting when I set up my company's implementation but even
that is probably not necessary.
I'll probably mainly keep Bullet's system in place, then. I might
at least replace Bullet's C++ "new" and/or malloc with GC
allocations, but I'm undecided on that.