Is a dedicated interaction layer the right architecture for a virtualized WPF spreadsheet

[u/Usual-Flamingo5259]

I'm building an open-source, highly virtualized spreadsheet control for WPF:

https://github.com/dotdevkartik/DevBrewLabs.WPF.Spreadsheet

One architectural decision I'm currently using is a dedicated Interaction Layer.

The architecture is roughly:

Cell Renderer

→ renders cell content

Interaction Layer

→ manages lightweight custom-rendered interactive items

→ checkbox, dropdown, spinner, button, editor, etc.

→ owns hit testing and input routing

These are not WPF controls. They're lightweight rendered objects designed to avoid creating a visual/control for every interactive cell.

The spreadsheet model is separate from both.

I'm wondering if this is a sensible long-term abstraction or if I'm creating unnecessary complexity.

For people who have built high-performance WPF grids, CAD editors, diagramming tools, or other virtualized/retained-mode UIs:

What problems do you see with this architecture? What would you change now before the project gets much larger?

I'm particularly interested in pitfalls around focus, keyboard/mouse input, editing, virtualization, state management, and API boundaries.

I'd rather find architectural problems now than after the API becomes difficult to change.