Themes for v2

• Improve performance and compatibility on non-Windows systems. The current ConsoleDriver architecture and implementation, especially w.r.t. Linux/curses has deep flaws and poor performance relative to WindowsDriver on Windows.
• Address the biggest bug farms. For example, we have almost no unit test coverage for ConsoleDrivers yet we continually get regressions and complex bugs in them.
• Update Visual Style. The current visual style is a bit awkward, deriving from the constrained simplicity of Midnight Commander. Other TUI frameworks of old, did some things right and we should take the best of them and update Terminal.Gui's visual style (Norton Command, TurboPascal). For example, see #2144.
• Colors. We must add true color support, support for more flexible theming, and end-user color choices. Also, support things like blink/underline and some sort of markup (e.g. attributed label/ANSI/etc...).
• Improve text editing and formatting. We learned a ton in the past few years by improving TextView, TextFormatter, etc... But we made some errors and things like word wrapping are still not as good as they need to be for a text-based library.
• Address weird/legacy API issues. Early gui.cs design decisions, combined with subsequent upgrades have led to areas of the API that just don't make sense to new devs. One example is how weird Window's Border and Padding work (and why FrameView exists at all). Another is the clunkiness of using ScrollView.
• Leverage Modern .NET Tech. Examples: Nullable Reference Types, using System.Rune vs. Nstack, and MAUI.

V2 Tenets for v2 (Unless you know better ones)

• Don't Overdo It. v2 will be a major overhaul and we can take breaking changes, but we try to not cause v1 developers too much pain in migrating.
• Always Better Performance. We ensure v2 is measurably faster, has lower latency, and feels snappier than v1. We don't make changes that regress performance.
• Simplify Getting Started. We invest in v2 capabilities that make it easier for devs to get started and are biased against things that make onboarding more difficult.

V2 Release Criterion

These are the criteria we will use to decide whether V2 can be Released.

After Beta, we will not accept any PR into v2_develop that does not meet these criteria.

V2 Release Goals

• TBD

Priority definitions for Issues

• 0 - Development is Blocked. Nothing is more important than fixing immediately. All pri 0 Issues must have an owner set. If the owner can't work on the Issue immediately, he/she will assign it to someone who can.

• 1 - Release Blocker - Issue needs to be resolved in order to ship the Release. We will not release until this issue is addressed. All pri 1 Issues must have an owner set. That individual is responsible for doing whatever it takes to get the Issue resolved as quickly as possible. If the owner can't work on the issue, they are responsible for finding someone else to take ownership.

• 2 - Nice to Have. We want this issue fixed in the Release, but we will ship without it and address it later if we can't get it done in time. Ideally, pri2 issues have an owner set, but don't have to.

• 3 - Not in Release. The Issue will not be addressed in this release but may be in a later one.

Beta Exit Criteria

• No known pri 0 or pri 1 bugs in the V2 Release Project

@tig will be the Release Owner. He will take responsibly for driving the team to release. He will do the structural work required to keep us organized and focused. He has final say on Issue priority and the final call on release readiness.