The InflatableAirlock part from Making History expansion is configured with

CrewCapacity = 0

and accomplishes dynamic crew capacity through ModuleAnimateGeneric.CrewCapacity

	MODULE
	{
		name = ModuleAnimateGeneric
		CrewCapacity = 1
		animationName = AirlockDeploy
		actionGUIName = Toggle Airlock
		startEventGUIName = Open Airlock
		endEventGUIName = Close Airlock
		allowAnimationWhileShielded = False
	}

This does not fire OnVesselWasModified, so CLS is not notified of the change, and does not update (or, more precisely, mark dirty) the CLS state of the vessel, leading to incorrect behavior.

For instance, launch a simple craft consisting of only a pod + inflatable airlock (initially retracted).
Checking the CLS window shows that CLS detects a single living space, consisting of only the pod, since the inflatable airlock starts with no crew capacity.

Deploying the airlock does not update the CLS state:

Attempting to perform a crew transfer from the pod to the deployed airlock does not work:

I don't really have any good solution for this -- looked over GameEvents again and did not find anything that looks like KSP will fire upon changing crew capacity of a part, or for ModuleAnimateGeneric completing its animation.

Options to consider:

1. Lobby TT/Squad to fire OnVesselWasModified for crew capacity changes, or add a OnPartCrewCapacityChanged event -- this would be the ideal solution, but it's not something we can do on our own.

2. Try to do something with onPartActionUIDismiss, assuming that the part action menu button is the only means of deploying/retracting the airlock. This would be a terrible, convoluted kludge, if it even works. This wouldn't work if animation is toggled using action groups.

3. As a stopgap measure, add a button to the CLS window that will force a refresh the active vessel's CLS state.

Since every part gets wrapped in a CLSPart object, it may be possible to add a delegate function to the animation event handler. If so, then that would allow capture of the event. The only concern is to ensure that the delegates are properly destroyed, or a memory leak will be created. I will investigate this.

Thanks for that insight -- I've figured out a solution, using ModuleAnimateGeneric.OnStop.
Will clean up and make a PR.

Merged. looks good. Testing.

Merged both PRs.