Part of the problem is well described in above posts. I have seen many proposed solutions, and none satisfies me (at this point).
I would like to add another part to that description of the problem.
Most behaviors are fps corrected. Meaning: their units are given in unit/second. The bullet speed is given in pixels/second. Meaning distance traveled / tick depends on the fps. To accurately detect a collision, at high speeds, at the inevitable sampling frequention 60/dt, it is needed to calculate from units in pixels/second to units in pixels/tick. And back. This, i found in the past, is very tricky. (well for me it is, i am no math wonder at all)
Conclusion (in my opinion) it is to difficult to use fps corrected behaviors, when dealing with high speeds. It is quite impossible to get them sync with the sample rate that goes with a fps. Rather build an own system based on units/tick.
This is an example.
https://drive.google.com/open?id=0B1SSu ... W5OcTRxV2M
Now, the max possible speed is now distance to travel * fps.
In this capx that comes to Speeds like 60.000 pixels/second, that is close to 1000 pixels / tick at 60 fps, theoretical, in practice probably 50.000 pixels/second.