That does sound strange. The package/filesystem mismatch shouldn't be a problem, with the exception that it's probably the reason you were prompted for the file location. That is a UI bug that needs to be fixed, it's essentially using the method we use with Java, where the local path will match up with packages. But the backend knows the path to the source won't match the package path. (that's also the reason it needs a valid package attached to a breakpoint - without that, we can pick the wrong class for breakpoints if there are several classes with the same name in different packages).
I'm not sure why it would be slow for steps. Most of the data we fetch on breakpoints is the stack frames, so it might depend either the depth or number of locals. The number of threads shouldn't matter unless we're pulling whole stack unnecessarily, but I'll double check that. I'll have to test this out with some extremes and see if something is slowing down in a non-linear way that could explain the speed.
My worry is that the slowness is the reason you had the program stopped while the SlickEdit UI didn't show it as being stopped - something timed out, and maybe got the two pieces out of sync, so I want to figure out the slow behavior. This may also explain the missing variables if we've timed out walking the stack and querying locals. I think it's a coincidence that the missing variables were defined in another jar - at the JVM/JDI level the source of a class isn't a distinguished, and would look the same to us as any other.
That still leaves the parsing problem that makes it so we can't resolve breakpoints at certain points in your source. Unless I find an example of that happening, the only thing you can do on your end is some of the test edits I suggested earlier to try to narrow down what sort of statement or declaration.
So for now I'll look and see if I can reproduce the slowness. At this point, it sounds like it was chaotic and slow enough for you to get it to stop, where I won't get a log of that for now, unless I get stumped on the performance.