arrowUp icon key carries upload, send, and directional meanings

[athz]

Problem

The built-in arrowUp icon name currently carries three different semantic responsibilities:

Consumer	Use	Meaning
FileInput	upload affordance	action: upload
ChatSendButton	default send glyph	action: send
sortable Table	ascending indicator	direction: ascending

The directional meaning is coherent with arrowDown and arrowsUpDown. The upload and send meanings only happen to share the same artwork today.

This becomes observable when a theme customizes the registry. Mapping arrowUp to an upload-tray glyph also changes the chat send button and breaks the visual pairing between the table's ascending and descending indicators. A single registry key therefore cannot be customized predictably across its current callsites.

Current architecture

The current icon architecture separates shared semantic names from component-owned roles. That makes the boundary important:

• arrowUp should remain a directional name.
• Upload and send are reusable UI actions, not FileInput- or Chat-specific implementation details.
• Component-owned slot mappings can still be added later if a theme needs to remap one component role independently; that is a separate layer from the shared semantic vocabulary.

Proposed contract

Add two shared semantic names:

• upload
• send

Both would initially resolve to the existing upward-arrow artwork, so default rendering would not change. FileInput would use upload, ChatSendButton would use send, and sortable Table would keep arrowUp.

This lets a theme provide an upload-tray glyph without changing send or sort, and a send glyph without changing upload or sort.

Alternatives considered

Keep arrowUp for all three meanings

No source change, but registry customization remains coupled across unrelated actions and direction.

Add only component-owned slots

Slots are useful when one component role needs a different shared meaning. They do not by themselves provide shared upload or send meanings for themes to map to appropriate artwork. These two actions are expected to recur across components, so they belong in the shared semantic vocabulary first.

Scope and non-goals

• No default visual change.
• No change to arrowDown or arrowsUpDown; their current uses remain directional.
• No component-slot implementation in this proposal.
• No commitment to a specific upload or send drawing; themes continue to own artwork.

Suggested sequence

1. Settle the shared-name contract in a spec-only pull request.
2. Add the two names and default artwork aliases.
3. Migrate FileInput and ChatSendButton to the new names with focused registry tests and consumer documentation.

[athz]

One compatibility constraint from the current resolver is worth making explicit before implementation: icon resolution performs an exact lookup by semantic name. A shipped theme that defines arrowUp but not upload or send would not inherit its own arrow artwork for the new names; the callsite would fall through to the core default instead.

The spec therefore needs every shipped theme registry to initialise upload and send from that theme's existing arrowUp artwork in the same implementation change, with preservation tests across the shipped registries. Preserving only the core default would still create a themed visual regression.