I can do a quick pseudo-code :

It's basically a dumb down version of the standard host-authoritative client prediction.

struct Vector
{
    float x, y;
};

struct Inputs
{
    int mouse_vx;
    int mouse_vy;
    int mouse_buttons;
};

struct Player
{
    Vector pos;
    Vector vel;

    void update(Inputs inputs)
    {
        // .....
        // ....
        // ... 
        // ..
    }
};

// inputs for each frame.
struct InputsPacket
{
    Inputs inputs;
    int    frameId;
};

// player updates on server.
struct SnapshotPacket
{
    Player player;
    int    frameId;
};

struct Client
{
    // list of inputs since last server update.
    std::list<InputsPacket> inputsQueue;
    
    // predicted player position on client.
    Player player;

    // the current frame id.
    int frameId;

    // initialise to a player position.
    void reset(Player _player, int _frameId)
    {
        inputsQueue.clear();
        
        player = _player;
        
        frameId = _frameId;
    }

    // update for frame.
    void update(Inputs inputs)
    {
        // increment frame id.
        frameId++;

        // create input packet.
        InputsPacket inputPacket(inputs, frameId);

        // cache input packet.
        inputsQueue.push_front(inputPacket);

        // update player.
        player.update(inputs);
        
        // send latest input packet.
        sendToServer(inputPacket);
    }

    // remove inputs from frame id, down to the oldest. 
    bool acknowledgeFrameId(int frameId)
    {
        // iterate inputs frames that haven't been acknowledged yet.
        for(std::list<InputsPacket>::iterator it = inputsQueue.begin(); it != inputsQueue.end(); ++it)
        {
            // found matching inputs frame.
            if(it->frameId == frameId)
            {
                // erase older inputs. We won't need them anymore.
                inputsQueue.erase(it, inputsQueue.end());
                return true;
            }
        }

        // couldn't find the inputs for that frame. 
        return false;
    }

    // host send us a player update for that frame id.
    void receiveFromServer(SnapshotPacket snapshotPacket)
    {
        // remove inputs up to the frame id.
        if(acknowledgeFrameId(snapshotPacket.frameId) == false)
        {
            // frame id is invalid. don't do anything.
            return;
        }

        // rewind player to the server frame id.
        player = snapshotPacket.player;

        // replay inputs that haven't been acknowledged, from oldest to newest.
        for(std::list<InputsPacket>::reverse_iterator it = inputsQueue.rbegin(); it != inputsQueue.rend(); ++it)
        {
            // update player.
            player.update(it->inputs);
        }
    }
}

1. Client stores input for each frame and sends the input along with the frame number.

2. When client receives a world update from server, it sets the clients m_frame variable to what the update says (provided that it's the most recent update, otherwise client ignores it.)
3. Client rewinds the player position to what the update says. Removes old frame from the cache, since we won't need them anymore.
4. replay all inputs from after the server frame id, up to the latest.



And that's about it, basically. No messing about with latency and whatnot. It's all taken care of automatically, you'll just have more frames to replay when the latency increases. At least, I don't think you have to do anything.

The rest of the standard client-side predictions are just optimisations, not really affecting the general algorithm.

EDIT : BTW, if your transport is limited to UDP (aka not reliable), instead of sending a single inputs packet per update from the client, send the entire inputsQueue, which is in effect the list of inputs that haven't been acknowledged by the server. Or just ignore packet loss all together send single frames, or a couple of frames at a time.

EDIT 2: bugs!

Does the client (predicted) frame change smoothly and monotonically?

So when it predicts forward from the server provided state (latency / time_per_frame) times, the value is guaranteed to be higher than equal to what it was last frame, and theres no fluctuations in either latency / frame time (or you apply a smoothing function somewhere). I assume the server applies the client input at exact same frames as client does, and for exact same length of time.