I have fixed a small bug that was making the slot to advance right after the device was inserted.

When the program enters the usbFunctionWrite() it compares the state of the LEDs against the last known state. If there is a change then one of the LOCK keys has been pressed and toggled its state.
The problem was related with the difference between the initialization value of LED_state variable with the first LED status reported (sent) by the host computer. The initialization LED_stat variable is 0xFF and the LED report is always 00000SCN being the 3 LSBits the state of SCROLL, CAPS and NUM lock. So the first compare, performed by a XOR would always result as a non zero. Then if the NUM LOCK was not set the XOR of its bit with the first state would always result in '1' and the slot was incremented.
The same occurred for CAPS LOCK, then the amount of taps on the CAPS Lock would vary from 4 to five.
The effect on SCROLL lock was hidden because up to now the password is being sent when the device is plugged in for the first time.

The bug fix was simple: The only time the LED_state variable is equal to 0xff is during the initialization (remember, the 5 MSBits from the LED report sent by the computer are always '0'), so the following statement solved the problem.

	if (LED_state == 0xff) LED_state = data [0];

The whole function is shown below

usbMsgLen_t usbFunctionWrite(uint8_t * data, uchar len) {
    uint8_t changed; 
	
	if (LED_state == 0xff) LED_state = data [0]; 
	
	changed = data[0] ^ LED_state;
	if (!changed)
        return 1;
    else
	    LED_state = data[0];
        if (changed & CAPS_LOCK ) caps_toggle();

		if (changed & SCROLL_LOCK ) {     // scroll lock 
		       eeprom_read_block(messageBuffer, stored_password, sizeof(messageBuffer));
			   messagePtr = 0;
			   messageState = STATE_SEND;		
		}
		
		if (changed & NUM_LOCK ) {  // advance slot, roll back at maximum
			if (slot < MAX_PASSWORD_SLOTS-1) slot++; else slot=0;
		}
	return 1; // Data read, not expecting more
}

Well, now about the finding... My laptop has a standard keyboard with no numeric keys. Well, I have found that the NUM LOCK function is processed locally, I mean, it happens on the keyboard level, not at operating system level. The effect is that NUM LOCK on my laptop and probably on other laptops won't be able do advance the slot. It is a pity but it is not a loss, because the operation using NUM LOCK / SCROLL LOCK is a redundancy.