JMeter isn't hanging - if you have multiple thread groups doing other things too then they will run.
Your BSF sample is still in progress - the exec() you are running is part of your sample. Your sampler won't complete until the exec() has completed.
I attach a trivial example. Open it in JMeter, open the JMeter log (click on warning triangle top right) then run it. Then click on View Results Tree to see it play out.
There are two thread groups - one just runs a debug sampler every 5 seconds as a heart beat to show JMeter is still working fine.
The other group just runs a single iteration. It contains two Beanshell samplers with exec() - the first launches Google Chrome, which is well behaved. It should give you an extra tab in your browser with the JMeter home page loaded. You will notice however that the page takes much longer to load than for the sampler to complete - you're measuring the time it takes to launch the new tab, not load the page. Probably not what you would expect or want.
The second is Power Shell. This doesn't terminate and doesn't open a window so it is badly behaved. Go to Task Manager and kill it off. Bingo - your second sample completes.
Then stop the test to stop the heart beat.
Look at the results in the results tree - you only have the default status code (200) despite killing Power Shell, again probably not what you would expect or want, and the time taken by each.
JMeter's built in scripting languages make it very powerful and flexible to do whatever you want without coding your own beans, though if you know Java, creating your own beans is not hard since all the heavy lifting has already been done. However, just because you can launch commands from JMeter doesn't mean you should. It's not playing to its strengths and running WMWare's Power Client under Power Shell is adding a further layer, so far abstracted from JMeter that it would make deterministic behaviour in the script a nightmare to achieve. In this instance, I'd use a different tool to create the QA scripts.