You have a couple options depending on how complicated your situation is, but for the things you are mentioning I would say your first instinct is pretty close to what you want to do.
When you wish to display the path, go ahead and make a copy of your ball launched at the appropriate angle and run it forward without regard to framerate or drawing. You'll still step it forward in the same increments you normally would (to avoid high speed issues), you'll just start the next step immediately rather than wait for next frame as normal. You'll also want to keep track of the simulated time passed, as it's unlikely you'll want to trace out forever. You'll also need it for applying correct amounts of force as all physics will use the simulated timestep rather than the actual one.
Now, if your ball is going to affect the things it collides with, you'll have to include them in the simulation (and anything they hit) past that point, in which case you'll likely want to show a tracer "ghost" version of those objects as well. Obviously if this isn't an issue (or you can make it not an issue through design choices) it makes your problem quite a bit easier to manage. I'd make a copy of anything involved in the simulation for purposes of said simulation as that way you can affect them with your normal physics calculations without worrying about actually moving anything.
Every time you collide, figure out the new effects to the ball (primarily velocity) and continue running your simulation in a loop until either you stop (velocity under threshold) or you hit the end of your tracer (say, 5 seconds of simulated time, much less than that actually) For ease of calculation I'd set it up so you only trace the ball as things are right now, if that bounce will effect other obstacles and you want to stay accurate you'll have to update all of them as well should they be affected by anything moving in the simulation.
Once you have that data display just depends on how you want to handle it. You could have the simulated ball drop visible spheres at a regular rate during it's path, or you could play it in sections and let the tracer ball itself be seen. I would recommend that you only run the long calculation of what happens when the input factors change (direction/power difference) in order to cover up the extra time it takes to process.