Take a look at my little multi-player version of Asteroids, the mechanics are actually quite similar to a racing game where the cars have weapons:

http://mmoasteroids.wildbunny.co.uk/

If there's anyone else playing when you try it you might be able to see the mechanics you're after working.

My server is authoritive over everything except the position of each player; but to mitigate the inherent problems with that, the server simply clamps the maximum speed of each player so no cheating is possible.

I simulate on client and server - the only thing I don't do that you'll require is collision between players.

Racing and fighting games are the hardest, because of the latency involved.
The "easiest" option is to accept the latency of fully server-authoritative systems, so the effects of your actions aren't seen until you have a roundtrip from the server.
If you can't accept that latency, then you have to fake it. For example, you may detect a collision client side, and play the collision reaction on the client, and send a "I collided with object O at time T" message to the server, so the server knows to apply that collision behavior to that player, even if the server doesn't detect the collision.
Similarly, when the server detects a collision, it sends data to the client about it, and the client applies that behavior, even though the collision may not be visible client side.
What's extra hard is that players can move pretty far in the time of a RTT, when it's a racing game. On my screen, it may seem as if I'm winning; on your screen, it may seem as if you're ahead. Forward extrapolating displayed objects may help, but you have to use "smart" extrapolation that uses "plausible" behavior (breaking before a curve, turning with curves, accelerating out of a curve, etc) for it to work alright. And it still won't be perfect.

You could make the rule that just touching a player means you flip over and crash. Just add smoke to cover up the unavoidable correction :-)

Yeah latency can be a killer for high speed online games. 100ms latency can mean five to ten meters discrepancy at very high speeds (which fortunately, often means a more linear path and easier prediction, since the vehicles become less twitchy at high speeds). It's a bit weird to picture, but on two machines, both players see themselves leading the race, for example, with the other player behind by a car length.

prediction is also tricky, if you have lots of overtaking and chaotic behaviours.

Unfortunately there isn't much you can do, apart from doing a balancing act between interpolation and extrapolation methods. The best you can hope for is minimise the latency as much as you can (for example, peer to peer where each player directly broadcast their position to other players, with all the caveats attached). Whereas a client-server first has to go through a server to relay the player position. It's even worse in a peer to peer game if you have connectivity issues and 'forwarders' have to relay information between two or more unreachable players.

If the speeds are not so great, then it's less noticeable. Or you just may not be that bothered about accuracy and having cars 'behind' a little bit has no noticeable effect on the gameplay.

Games like Counterstrike mostly run on interpolation, with extrapolation thrown in for edge cases. It means the players are 'behind' their real position at any given moment in time, which can lead to some problems of its own. As for weapon management, the problem is not so difficult in the context of a client server. Google 'lag compensation source networking', which is fairly self-explanatory. That will give a reasonable accurate hit detection, albeit 'laggy', but is fairly resilient to cheating and adjustable to balance the playing field (players with high or low latency connections gets advantaged differently depending on which way you go with the compensation factor).

At the end of the day, you just cannot beat latency completely and you just have to deal with it.