Is there a reason you didn't use .net's hashset? Because of .net 2.0 I suppose?
.NET's HashSet is used in a few places, unless you're talking about an older version that had a conditional "HashSet" wrapper around Dictionary due to API holes on the Xbox360's compact framework.
If you're referring to the QuickSet, then it's mostly for minor performance reasons:
1) It offers greater reusability of underlying arrays. Resizing doesn't generate garbage, and a QuickSet<int> and a QuickList<int> can pull from the same pool of arrays.
2) It avoids GC involvement at the instance level by being a value type (while biting the bullet on all the complications that entails).
3) QuickSet's implementation is focused on enumeration speed. The elements are stored in a contiguous array, so enumeration does not require any memory hopping. Adds/removes are still competitive with the regular HashSet on most types.
4) The Quick collections are very raw and expose their guts. For example, the elements array can be accessed directly. This can be helpful when wanting to modify the state of a value type stored inside the set without removing and readding it.
Also there was this line:
loopFinished.Close();
Close does not exist for an AutoResetEvent I changed this to Dispose() instead. Is this acceptable? I tried looking online, but I couldn't find much.
Yup, that's fine. Close and Dispose do exactly the same thing on the desktop framework. If I remember correctly, I only used Close because of some old platform issue.
Finally all the threads were changed to tasks
You could also just delete the ParallelLooper entirely and supply another IParallelLooper implementation that wraps existing thread pools if they offer an efficient parallel for loop. The TPL's Parallel.For works great for this purpose; I only implemented the ParallelLooper because of platform holes.
Thread.Sleep was changed to Task.Delay inside of the spinlock class. The Thread.SpinWait was also changed to a Task.Delay, although if I read right between the differences in spinwait and sleep that is probably not the best thing to use, however I believe it should work correct?
I am not entirely familiar with the underlying mechanics of Task.Delay, but if it's functionally similar to Thread.Sleep, then it will work correctly. However, performance may be a problem. Certainly in the case of the spin wait, a Sleep or a blocking wait could produce nasty results, like surrendering the time slice too aggressively. The waiting portion of the SpinLock is probably best replaced by the SpinWait structure.
However, I would recommend just getting rid of the custom SpinLock entirely, and replacing its usages with the PCL-included SpinLock. This is yet another spot where the custom implementation only exists because of old platform support holes.
I'm extremely interested in a portable subset version of BEPU Physics. What's the likely hood of this happening soon? Would it be possible for me to port it over myself or is there a lot to change?
As you've encountered, there's not too much, just these areas left over from ye olde early XNA days. Reducing or eliminating the pain for PCL is something I'd like to do, but I have a history of doing a poor/slow job at maintaining compatibility across a lot of simultaneous targets. It's looking like v1.4.0, which I expect to package up as the stable release in the next couple of months, is going to be the last version which tries to maintain backwards compatibility with Xbox360 and WP7.
v2.0.0 will probably be the next version and will toss out as much cruft as possible, so it should be easier. (That, and early fiddling implies it will probably be at least twice as fast on many simulations, before taking into account SIMD types
)