The speed thing is the most overrated aspect of Roguelike design.  You
can only plan ahead the  number of moves you can reliably predict.  The
more random crap you throw into the simulation, the less the player can
plan ahead.

If the pattern of double-attacks for monsters is sufficiently random,
the player will not be able to safely rely on the monster only getting
one attack.  This forces the player to be even more conservative.
Instead of wondering: "Can I survive to the next turn?" it becomes "Can
I survive for two turns?", a much harder and more conservative
estimate.

The fundamental flaw with the attempts to make ultra-realistic speed
models is that roguelikes are very, very, turn-centric.  Damage is
usually resolved entirely in the instant of the turn.  Movement occurs
instantly when the creature gets a turn.  You can try and change these
things - apply damage over time for all attacks, track sub-grid
movement, etc.

Having said that, I'll point out there are two things a speed system
must do:
1) Track dungeon time.  This is used for how long it takes effects to
wear off, when damage-over-time effects like poison proc, etc.
2) Determine turn order.  A simple function that determines the next
mob to act.

Please note that it is important to make #1 independent of the player
and mob speeds.

My own suggestion for speed systems (which you can see in POWDER, You
Only Live Once, and  Letter Hunt, the latter two providing source code)
is modelled off how I thought Nethack used to work.  (Nethack as since
moved to the sort of overengineered speed systems I dislike).  It is
built on the premise of making it as completely simple as absolutely
possible.

We divide creatures into 4 classes of speeds.  Slow, Normal, Fast, and
Fast & Quick.  In terms of effective speed, Slow is 66%, Normal 100%,
Fast 133%, and Fast & Quick 166%.  This gives both a wide range of
speeds and also ensures each speed is significantly different from the
other speed levels.  The latter point is one of my design principles -
I try to avoid continuous scales where one improves by 1% at a time -
that doesn't register on the players "Cool, new ability!" meter.

Anyways, implementation is straightforward.  Track the current phase
which goes through the pattern FAST, NORMAL, SLOW, QUICK, NORMAL.

Then your time loop is...
while (1)
{
  increment_phase();
  for all mobs
  {
    if (phase is NORMAL or SLOW)
    {
      // Apply time to the mob.
      mob->heartbeat();
    }
    if (mob->actsThisPhase(phase))
    {
      mob->getsTurn();
    }
  }

Note that you can have both SLOW and FAST and end up with 100% of the
phases, albeit in a different order.

The heartbeat method is the constant in dungeon-time callback to do all
the maintaince, such as regeneration, hunger, poison, etc, that should
be independent of the creatures actual speed.

One thing to note about this system is that it is simple enough for the
player to figure out.  When you are FAST facing a NORMAL monster, you
can easily pick up the pattern of double moves and thereby know if this
move will be a "free" move or not.  This lets you perform, say, a two
turn action knowing you can complete it before the monster can react.
Of course, this also implies that you *know* that the actions only take
two turns.  Having variable timed actions throws this out the window -
even if I know zapping a wand is faster than attacking, I don't know
how many fractional time units are left until the monster attacks next,
so can't determine if I can zap twice or attack once.

Many people seem to think this sort of knowledge is a bad thing.
They'd rather the player know as little as possible.   This, however,
turns every battle into an FPS twitch fest.  One can only act on the
immediate information at hand as any forward planning  is guaranteed to
be disrupted by the RNG.  Roguelikes, IMHO, occupy a neat place between
twitch-immediacy and long-term strategy.  This tactical layer is
facilitated by being able to look a bit forward, but not too far
forward.

Note that the deterministic timing may allow more precise back & hack,
but any speed system allows the faster player to back & fire.  The
limit placed in roguelikes is usually stumbling into other enemies, or
having other enemies stumble into you, while you prance about trying to
wear down the too powerful enemy.

Martin Read's Dungeon Bash uses a similar system to this, except with
four phases:

SLOW,NORMAL,SLOW,FAST

In his system, a mob gets a turn on any phase <= to its speed.  SLOW
monsters act on SLOW turns, NORMAL on SLOW and NORMAL, and FAST on all
turns.

He's got an out of date comment, however:
        /* Player is always speed 1, for now. */
        if (action_speed <= u.speed)
I think u.speed isn't always 1 any more - there are ways to gain both a
malus and a bonus.

Hell, *one* monster speed is enough.

Besides, there's always the option of making sure there is at least one
monster the player cannot possibly outrun. You can't outrun an air
elemental in Nethack or a quickling king in ADOM.

Crawl's Haste spell is nice, but you can't (safely) use it all the time
because of the magic contamination factor.