In Spine 4.2, the behavior you're experiencing with attachment mixing is due to how animations handle attachment keys. When transitioning from an animation with attachment keys (like Creation Animation 1) to one without (like Idle Animation 1), the attachments revert to the setup pose unless the second animation also keys the attachments. This is consistent with the changes made in Spine 4.1 and later, where animations mix back to the setup pose unless otherwise specified. To achieve the desired outcome you can use the attachmentThreshold setting to control how attachments are applied during mixing.

In older versions of Spine, the skeleton could keep attachments or other state after an animation was applied. In newer versions of Spine, AnimationState (normally) restores properties that were keyed in animations to the setup pose if they are not keyed in subsequent animations (unless clearTrack, clearTracks, or trackEnd is used). This makes it easier to control the skeleton state when many animations are applied. Previously you would very often have state sticking around that was keyed in a previous animation, but isn't keyed in the current animation. This leads to keying everything so you can be sure what your skeleton state is, but keying everything is error prone and negatively affects performance.

attachmentThreshold controls whether you get attachment keys from the animation you are mixing from or the animation you are mixing to (or the setup pose, if not keyed in the animation you are mixing to) during the mix. After the mix, you will always get the attachment keys of the current animation (or the setup pose).

If you want keyed values to persist after an animation is applied, like they used to, then you'd need to modify the AnimationState source code. I probably posted something about how to do that in the past, we could probably dig it up. However, I suggest moving to the new behavior (especially if starting a new project), as it is much easier to manage. You really don't want all your animations to need to key everything.

If you want an animation to continue to affect the skeleton after it is no longer applied, in some cases you can continue to apply the animation instead of letting it finish. If you are using animations for behavior like equipping an item, I suggest setting attachment visibility explicitly by using game state, rather than having the attachment visible as a side effect of an animation that was applied in the past and is no longer being applied.

As for the difference between AttachmentTimeline and SequenceTimeline, AttachmentTimeline has this code:

if (direction == out) {
	if (blend == setup) setAttachment(skeleton, slot, slot.data.attachmentName);
	return;
}

if (time < frames[0]) {
	if (blend == setup || blend == first) setAttachment(skeleton, slot, slot.data.attachmentName);
	return;
}

SequenceTimeline has this:

if (time < frames[0]) {
	if (blend == setup || blend == first) slot.setSequenceIndex(-1);
	return;
}

Given this, SequenceTimeline is missing logic that it should probably have so that it matches the AttachmentTimeline behavior. Since they are so similar, I think they should behave the same. We will make this change and test internally before publishing the change. Edit: the change is here, soon to be ported to other runtimes.