Replacing the physics library isn’t something that you would typically pick up and blow through in a day, it would be a significant undertaking. Consider also that if you still need some features of PhysX like cloth simulation and you aren’t planning on doing your own cloth simulation then you’re just going to be running two physics engines at a time. And that sounds like a recipe for disaster. Both PhysX and Box2D are implemented in UE4, so if you start by reading say the integration guide for PhysX and tracking things down in UE4 source you’ll probably find most of the major stuff quite easily.
As to how much work it is to implement a physics engine, there are the basics of wrapping the necessary entry points and ticking the physics engine, probably something anyone could do in an afternoon. Then beyond this you need to do all the little things that would be necessary for normal users to actually use your physics engine… things like generate collision geometry in whatever odd buffer format that Physics Engine Y needs (hopefully with the aid of the UE4 editor) and render the actual debug geometry for the physics primitives to help you debug your scene. You also need to tie in collision filtering, raycasts, sweeps (if supported). Then add world controls to tune the physics parameters of the physics world.
These are just off the top of my head, I’ve integrated PhysX and ODE in the past. PhysX is pretty easy to get going, like I said you can easily do it in an afternoon (assuming this carries over to about any physics engine) and if you work with a bunch of other hackers you might only need that base level integration. But working with artists and such, if you want to decouple their physics workflow from your programmers you’ll need a more polished integration and that effort is a lot more work and a lot of grep’ing and understanding UE code.