Temporarily disabling a capability differs from removing its shortcut. Combining those states makes people rebuild their arrangement when they enable it again. The earlier platform-group story addressed menu hierarchy; this article looks more closely at hidden individual preferences and the slots preserved during reordering.
Do not hide an unpin inside disabled state
Disable changes only enabled to False. A True pinned value remains True; enable likewise changes only enabled. The toolbar receives entries satisfying both values, so an item disappears while disabled and reveals its retained pin when enabled again. Stored preference and current visibility are separate computations.
Unpin instead changes only pinned to False, leaving the capability usable in the menu. Someone can tidy the toolbar without disabling the underlying feature. Removing that distinction makes it difficult to tell whether an absent shortcut means unavailable work or a layout choice. The same empty space on screen need not correspond to the same saved state.
Normalize restored data rather than trusting it blindly
pluginPreferences accepts only correctly shaped records from a restored array and keeps the first valid occurrence of a repeated programId. pluginItems joins preferences to current program definitions. An absent or foreign definition is not revived on screen through a familiar label alone.
Consequently a stored pinned=True is not a guarantee of a toolbar button under every condition. A readable definition and enabled state are also needed. I wanted to retain the user's choice without fabricating a usable shortcut for an unavailable connection. Restoration reads both preserved preference and currently available target, rather than treating either as sufficient on its own.
First pinning and repeated pinning have different effects
A new pin moves its registration to the end, after existing pins. Pinning an already pinned entry leaves its order unchanged. Repeating the same preference request must not keep rearranging the toolbar. That small idempotency rule also protects a person's arrangement from an automation caller retrying a settings command.
Existing tests compare the original array as well, checking that it was not mutated. Returning a new result makes before/after preference comparison straightforward. The menu's name ordering and the toolbar's deliberate pin order serve different purposes. Applying one sorting rule indiscriminately would discard the distinction the interface was meant to preserve.
Dragging refills only the visible slots
movePinnedPlugin collects array positions only for entries that are enabled, pinned and currently available. It rearranges their visible sequence and writes that sequence back into the same slots. A disabled registration between them is neither deleted nor moved as an incidental side effect.
An existing test transforms A, disabled C, B into B, disabled C, A. C's complete preference must remain unchanged, as must the original input. This excludes hidden items from reordering without disturbing unrelated saved state. Comparing only the two visible buttons would miss the preservation condition in the middle of the stored array.
Refuse a stale drag target instead of moving a substitute
A disabled, unpinned or missing definition cannot be moved: PLUGIN_MOVE_UNAVAILABLE is returned. A beforeId must also identify a currently visible pinned entry. Moving an item before itself returns the current sequence. If state changed after the screen opened, the function does not choose a similarly named button as a substitute.
The command contract also names profile, workspace and tab. Even an arrangement request needs a clear owner. This content task did not drag the original UI or change its preferences. The account comes from comparing functions and existing tests, while the narrower behavior actually implemented in the new example is identified separately.
Preserving small preferences is part of the feature
The shared module tests independent enabled/pinned values and automatic registration retaining choices as part of its twenty-four checks. It does not implement actual menu sorting or drag reordering. A small example that explains a contract should not be introduced as a complete reproduction of every original screen behavior.
Frequently used shortcut positions become part of a person's work habits in a tailored manager. Wiping those habits during every feature addition forces relearning. I wanted to show exactly where a preference survives being hidden and where a reorder changes only visible slots. These modest state rules can matter as much to continued usability as the larger capability behind a button.