Note: For issues on how the interface is presented to the player, see #3602.

There are some issues with how the game interface code is organized:

• Interface calls are intertwined with world interaction and update operations.
  This makes it extremely hard to reason about what functions and how can prompt for player input, which is extremely important for non-player interactions and testing. Ideally we'd have game world and everything within it be contained in a dedicated "game state", while the interface layer drives the world updates by sending over avatar actions (e.g. "drop these 5 items there", or "burst-fire at that monster with this gun", or "skip turn"). With this separation, we would be able to build game state as a separate library, which would help with testing.
• SDL and curses code is intertwined with interface code, and is only distinguished by the TILES define.
  This makes it hard to trace the workings of interface internals, and requires building the game (and tests) twice in order to test some interface changes. Possible solution is to split off SDL and curses code into separate libraries that can be used by a backend-agnostic abstraction layer - this would also allow implementing new backends, for example a backend that can perform UI tests in headless mode.
• There is little order when it comes to reusable UI code.
  While many specific functions, snippets and entire "widgets" are reusable, naming and calling conventions are all over the place. Some use builder patterns, some use obscure input handling rules, some mimic raw curses printing functions, some spawn their own UI layer, but resize and position it so it looks like it's part of the underlying layer. There is little code that deals with UI layouts, usually it's just raw calculations of cursor position in window.
  We could benefit from a centralized UI library, with clearly defined widgets (and Lua bindings), so mundane operations like cursor movement, mouse input and layout wouldn't have to be handled on an individual basis.

Resolving these issues would in the long run help with implementing advanced ui features, such as #2941 or universal mouse support.