This is most likely the same issue reported in #137, although I don't use mount sets and similar.

The issue can be reproduced by doing the following:

• Equip set A.
• Enter combat, and select set B to be equipped. When leaving combat, set B is equipped correctly.
• Change back to set A out of combat.
• Enter combat, queue up an item (for example a trinket).
• Leave combat, notice that your trinket gets changed, but also notice that your active set gets marked as set B.

Digging through the code, the problem appears to be that changing sets in combat sets ItemRack.CombatSet to the new value. As long as you don't change sets in combat again, this value is never changed and will continue to cause issues. When an item is queued in combat, the ItemRack.ProcessCombatQueue() function will set the following:
ItemRackUser.Sets["~CombatQueue"].oldset = ItemRack.CombatSet

When combat drops after queuing an item, the EndSetSwap for the ~CombatQueue set is called:

if not string.match(setname,"^~") then --do not list internal sets, prefixed with ~
			ItemRackUser.CurrentSet = setname
			ItemRack.UpdateCurrentSet()
		elseif ItemRackUser.Sets[setname].oldset then
			if ItemRack.printdebug then
				print("EndSetSwap: Setting CurrentSet = " .. ItemRackUser.Sets[setname].oldset)
				print("EndSetSwap: Setting oldset for " .. setname .. " to nil")
			end
			-- if this is a special set that stored a setname, set current to that setname
			ItemRackUser.CurrentSet = ItemRackUser.Sets[setname].oldset   ---- the problem occurs on this line
			ItemRackUser.Sets[setname].oldset = nil
			ItemRack.UpdateCurrentSet()
		end

Since ItemRackUser.CurrentSet is set to combatqueue's oldset, it sets CurrentSet to set B, even though you previously equipped set A.

I found that adding the following to the top of the ItemRack.EndSetSwap method solved the issue for me:

function ItemRack.EndSetSwap(setname)
	ItemRack.SetSwapping = nil
        ItemRack.CombatSet = nil -- added this line.

This ensures when you swap sets out of combat the first time to set B, CombatSet is reset and will not cause issues for the combat queue later on.

I don't know the addon well enough to know if this would cause issues elsewhere.

As a sidenote, when using per-set queues, if set A has auto-queues, and set B has no auto-queues for the same items, equipping set B in combat will trigger a swap on the auto-queue slots and you may end up with the wrong items in those slots compared to how set B is configured (but auto-queue will be disabled).