diff --git a/docfx/docs/terminology-before-after.md b/docfx/docs/terminology-before-after.md
new file mode 100644
index 0000000000..7a1b36c0ae
--- /dev/null
+++ b/docfx/docs/terminology-before-after.md
@@ -0,0 +1,189 @@
+# Before and After Comparison
+
+## API Naming Comparison
+
+### Current (Confusing) API
+
+```csharp
+// What is "Top"? Top of what?
+Application.Top?.SetNeedsDraw();
+
+// How does "Top" relate to "TopLevels"?
+if (Application.TopLevels.Count > 0)
+{
+    var current = Application.Top;
+}
+
+// Is this the top view or something else?
+var focused = Application.Top.MostFocused;
+```
+
+**Problems:**
+- "Top" is ambiguous - top of what?
+- Relationship between `Top` and `TopLevels` is unclear
+- Doesn't convey that it's the "currently running" view
+
+### Proposed (Clear) API
+
+```csharp
+// Immediately clear: the currently active view
+Application.Current?.SetNeedsDraw();
+
+// Clear relationship: Current is from the RunStack
+if (Application.RunStack.Count > 0)
+{
+    var current = Application.Current;
+}
+
+// Self-documenting: working with the current view
+var focused = Application.Current.MostFocused;
+```
+
+**Benefits:**
+- `Current` is immediately understandable
+- `RunStack` describes both structure (stack) and content (running views)
+- Clear relationship: `Current` is the top item in `RunStack`
+
+## Real-World Code Examples
+
+### Example 1: Modal Dialog
+
+**Before:**
+```csharp
+public static void ShowError(string message)
+{
+    var dialog = new Dialog("Error", message);
+    Application.Run(dialog);
+    
+    // Wait, is Application.Top now the dialog or the original window?
+    Application.Top?.SetNeedsDraw();
+}
+```
+
+**After:**
+```csharp
+public static void ShowError(string message)
+{
+    var dialog = new Dialog("Error", message);
+    Application.Run(dialog);
+    
+    // Clear: we're working with whatever is currently active
+    Application.Current?.SetNeedsDraw();
+}
+```
+
+### Example 2: Checking Active Views
+
+**Before:**
+```csharp
+// Confusing: TopLevels vs Top
+public bool HasModalDialog()
+{
+    return Application.TopLevels.Count > 1 
+        && Application.Top?.Modal == true;
+}
+```
+
+**After:**
+```csharp
+// Clear: multiple items in the RunStack means we have modals/overlays
+public bool HasModalDialog()
+{
+    return Application.RunStack.Count > 1 
+        && Application.Current?.Modal == true;
+}
+```
+
+### Example 3: Refreshing the Screen
+
+**Before:**
+```csharp
+// What does "Top" mean here? 
+public void RefreshUI()
+{
+    Application.Top?.SetNeedsDraw();
+    Application.Top?.LayoutSubviews();
+}
+```
+
+**After:**
+```csharp
+// Clear: refresh the currently active view
+public void RefreshUI()
+{
+    Application.Current?.SetNeedsDraw();
+    Application.Current?.LayoutSubviews();
+}
+```
+
+## Documentation Clarity
+
+### XML Documentation Comparison
+
+**Before:**
+```csharp
+/// <summary>The Toplevel that is currently active.</summary>
+/// <value>The top.</value>
+public static Toplevel? Top { get; }
+```
+*Question: What does "The top" mean? Top of what?*
+
+**After:**
+```csharp
+/// <summary>
+/// Gets the currently active view with its own run loop.
+/// This is the view at the top of the <see cref="RunStack"/>.
+/// </summary>
+/// <remarks>
+/// The current view receives all keyboard and mouse input and is 
+/// responsible for rendering its portion of the screen. When multiple 
+/// views are running (e.g., dialogs over windows), this represents 
+/// the topmost, active view.
+/// </remarks>
+public static Toplevel? Current { get; }
+```
+*Clear: Self-explanatory with helpful context*
+
+## Consistency with .NET Ecosystem
+
+### Similar Patterns in .NET
+
+```csharp
+// Threading
+Thread.CurrentThread          // NOT Thread.Top
+Thread.CurrentContext         // NOT Thread.TopContext
+
+// Web Development  
+HttpContext.Current           // NOT HttpContext.Top
+SynchronizationContext.Current // NOT SynchronizationContext.Top
+
+// Terminal.Gui (Proposed)
+Application.Current           // Follows the pattern!
+```
+
+### Breaking the Pattern
+
+If Terminal.Gui used the .NET pattern:
+- `Application.CurrentToplevel` - Too verbose, redundant
+- `Application.Current` - Perfect! Type provides the context
+
+## Summary
+
+| Aspect | Before (Top) | After (Current) |
+|--------|--------------|-----------------|
+| **Clarity** | Ambiguous | Clear |
+| **Intuitiveness** | Requires explanation | Self-documenting |
+| **Consistency** | Unique to Terminal.Gui | Follows .NET patterns |
+| **Verbosity** | Short but unclear | Short and clear |
+| **Learnability** | Requires documentation | Obvious from name |
+| **Maintenance** | Confusing for new devs | Easy to understand |
+
+## Conclusion
+
+The proposed terminology (`Application.Current` and `Application.RunStack`) provides:
+- **Immediate clarity** without needing to read documentation
+- **Consistency** with established .NET patterns
+- **Better code readability** through self-documenting names
+- **Easier maintenance** for both Terminal.Gui and applications using it
+
+The old names (`Application.Top` and `Application.TopLevels`) will remain available during a deprecation period, ensuring backward compatibility while encouraging migration to the clearer terminology.
diff --git a/docfx/docs/terminology-diagrams.md b/docfx/docs/terminology-diagrams.md
new file mode 100644
index 0000000000..14c2b9aef5
--- /dev/null
+++ b/docfx/docs/terminology-diagrams.md
@@ -0,0 +1,326 @@
+# Terminology Proposal - Visual Diagrams
+
+This document provides visual diagrams to illustrate the proposed terminology changes for Terminal.Gui's `Application.Top` and related APIs.
+
+## Current vs Proposed Terminology
+
+```mermaid
+graph TB
+    subgraph Current["Current Terminology (Confusing)"]
+        A1[Application.Top]
+        A2[Application.TopLevels]
+        A3[Toplevel class]
+        
+        A1 -.->|"unclear relationship"| A2
+        A1 -.->|"what is 'Top'?"| A3
+        
+        style A1 fill:#ffcccc
+        style A2 fill:#ffcccc
+    end
+    
+    subgraph Proposed["Proposed Terminology (Clear)"]
+        B1[Application.Current]
+        B2[Application.RunStack]
+        B3[Toplevel class<br/>keep as-is]
+        
+        B1 -->|"top item in"| B2
+        B1 -.->|"returns instance of"| B3
+        
+        style B1 fill:#ccffcc
+        style B2 fill:#ccffcc
+        style B3 fill:#ffffcc
+    end
+    
+    Current -.->|"rename to"| Proposed
+```
+
+## Application.Current - Stack Relationship
+
+```mermaid
+graph TD
+    subgraph RunStack["Application.RunStack (ConcurrentStack&lt;Toplevel&gt;)"]
+        direction TB
+        Dialog[Dialog<br/>Modal: true]
+        Window[Window<br/>Modal: false]
+        MainView[Main Toplevel<br/>Modal: false]
+        
+        Dialog -->|"on top of"| Window
+        Window -->|"on top of"| MainView
+    end
+    
+    Current[Application.Current] -->|"returns top of stack"| Dialog
+    
+    style Current fill:#ccffcc,stroke:#339933,stroke-width:3px
+    style Dialog fill:#ffd6cc,stroke:#ff6633,stroke-width:2px
+    style Window fill:#cce6ff
+    style MainView fill:#cce6ff
+```
+
+## Before: Confusing Naming Pattern
+
+```mermaid
+sequenceDiagram
+    participant Dev as Developer
+    participant Code as Code
+    participant API as Application API
+    
+    Dev->>Code: Application.Top?
+    Code->>Dev: 🤔 Top of what?
+    
+    Dev->>Code: Application.TopLevels?
+    Code->>Dev: 🤔 How does Top relate to TopLevels?
+    
+    Dev->>Code: Is this the topmost view?
+    Code->>Dev: 🤔 Or the currently running one?
+    
+    Note over Dev,API: Requires documentation lookup
+    Dev->>API: Read docs...
+    API->>Dev: Top = currently active view
+```
+
+## After: Self-Documenting Pattern
+
+```mermaid
+sequenceDiagram
+    participant Dev as Developer
+    participant Code as Code
+    participant API as Application API
+    
+    Dev->>Code: Application.Current?
+    Code->>Dev: ✓ Obviously the current view!
+    
+    Dev->>Code: Application.RunStack?
+    Code->>Dev: ✓ Stack of running views!
+    
+    Dev->>Code: Current from RunStack?
+    Code->>Dev: ✓ Top item in the stack!
+    
+    Note over Dev,API: Self-documenting, no docs needed
+```
+
+## .NET Pattern Consistency
+
+```mermaid
+graph LR
+    subgraph NET[".NET Framework Patterns"]
+        T1[Thread.CurrentThread]
+        T2[HttpContext.Current]
+        T3[SynchronizationContext.Current]
+    end
+    
+    subgraph TG["Terminal.Gui (Proposed)"]
+        T4[Application.Current]
+    end
+    
+    NET -->|"follows established pattern"| TG
+    
+    style T4 fill:#ccffcc,stroke:#339933,stroke-width:3px
+    style T1 fill:#e6f3ff
+    style T2 fill:#e6f3ff
+    style T3 fill:#e6f3ff
+```
+
+## View Hierarchy and Run Stack
+
+```mermaid
+graph TB
+    subgraph ViewTree["View Hierarchy (SuperView/SubView)"]
+        direction TB
+        Top[Application.Current<br/>Window]
+        Menu[MenuBar]
+        Status[StatusBar]
+        Content[Content View]
+        Button1[Button]
+        Button2[Button]
+        
+        Top --> Menu
+        Top --> Status
+        Top --> Content
+        Content --> Button1
+        Content --> Button2
+    end
+    
+    subgraph Stack["Application.RunStack"]
+        direction TB
+        S1[Window<br/>Currently Active]
+        S2[Previous Toplevel<br/>Waiting]
+        S3[Base Toplevel<br/>Waiting]
+        
+        S1 -.-> S2 -.-> S3
+    end
+    
+    Top -.->|"same instance"| S1
+    
+    style Top fill:#ccffcc,stroke:#339933,stroke-width:3px
+    style S1 fill:#ccffcc,stroke:#339933,stroke-width:3px
+```
+
+## Usage Example Flow
+
+```mermaid
+sequenceDiagram
+    participant App as Application
+    participant Main as Main Window
+    participant Dialog as Dialog
+    
+    Note over App: Initially empty RunStack
+    
+    App->>Main: Run(mainWindow)
+    activate Main
+    Note over App: RunStack: [Main]<br/>Current: Main
+    
+    Main->>Dialog: Run(dialog)
+    activate Dialog
+    Note over App: RunStack: [Dialog, Main]<br/>Current: Dialog
+    
+    Dialog->>App: RequestStop()
+    deactivate Dialog
+    Note over App: RunStack: [Main]<br/>Current: Main
+    
+    Main->>App: RequestStop()
+    deactivate Main
+    Note over App: RunStack: []<br/>Current: null
+```
+
+## Terminology Evolution Path
+
+```mermaid
+graph LR
+    subgraph Current["v2 Current State"]
+        C1[Application.Top]
+        C2[Application.TopLevels]
+        C3[Toplevel class]
+    end
+    
+    subgraph Phase1["Phase 1: Add New APIs"]
+        P1[Application.Current]
+        P2[Application.RunStack]
+        P3[Toplevel class]
+        P1O["Application.Top<br/>[Obsolete]"]
+        P2O["Application.TopLevels<br/>[Obsolete]"]
+    end
+    
+    subgraph Phase2["Phase 2-4: Migration"]
+        M1[Application.Current]
+        M2[Application.RunStack]
+        M3[Toplevel class]
+        M1O["Application.Top<br/>[Obsolete Warning]"]
+        M2O["Application.TopLevels<br/>[Obsolete Warning]"]
+    end
+    
+    subgraph Future["Phase 5: Future State"]
+        F1[Application.Current]
+        F2[Application.RunStack]
+        F3["IRunnable interface"]
+        F4["Toplevel : IRunnable"]
+    end
+    
+    Current --> Phase1
+    Phase1 --> Phase2
+    Phase2 --> Future
+    
+    style P1 fill:#ccffcc
+    style P2 fill:#ccffcc
+    style M1 fill:#ccffcc
+    style M2 fill:#ccffcc
+    style F1 fill:#ccffcc
+    style F2 fill:#ccffcc
+    style F3 fill:#ffffcc
+    style P1O fill:#ffcccc
+    style P2O fill:#ffcccc
+    style M1O fill:#ffcccc
+    style M2O fill:#ffcccc
+```
+
+## Comparison: Code Clarity
+
+```mermaid
+graph TB
+    subgraph Before["Before: Application.Top"]
+        B1["var top = Application.Top;"]
+        B2{"What is 'Top'?"}
+        B3["Read documentation"]
+        B4["Understand: currently active view"]
+        
+        B1 --> B2 --> B3 --> B4
+    end
+    
+    subgraph After["After: Application.Current"]
+        A1["var current = Application.Current;"]
+        A2["✓ Immediately clear:<br/>currently active view"]
+        
+        A1 --> A2
+    end
+    
+    Before -.->|"improved to"| After
+    
+    style B2 fill:#ffcccc
+    style B3 fill:#ffcccc
+    style A2 fill:#ccffcc
+```
+
+## Migration Phases Overview
+
+```mermaid
+gantt
+    title Migration Timeline
+    dateFormat YYYY-MM
+    section API
+    Add new APIs (backward compatible)           :done, phase1, 2024-01, 1M
+    Update documentation                          :active, phase2, 2024-02, 1M
+    Refactor internal code                        :phase3, 2024-03, 2M
+    Enable deprecation warnings                   :phase4, 2024-05, 1M
+    Remove deprecated APIs (major version)        :phase5, 2025-01, 1M
+    
+    section IRunnable Evolution
+    Design IRunnable interface                    :future1, 2024-06, 3M
+    Implement IRunnable                           :future2, 2024-09, 3M
+    Migrate to IRunnable                          :future3, 2025-01, 6M
+```
+
+## Key Benefits Visualization
+
+```mermaid
+mindmap
+  root((Application.Current<br/>& RunStack))
+    Clarity
+      Self-documenting
+      No ambiguity
+      Immediate understanding
+    Consistency
+      Follows .NET patterns
+      Thread.CurrentThread
+      HttpContext.Current
+    Maintainability
+      Easier for new developers
+      Less documentation needed
+      Reduced cognitive load
+    Future-proof
+      Works with IRunnable
+      Supports evolution
+      Non-breaking changes
+    Migration
+      Backward compatible
+      Gradual deprecation
+      Clear upgrade path
+```
+
+## Summary
+
+These diagrams illustrate:
+
+1. **Clear Relationships**: The new terminology makes the relationship between `Current` and `RunStack` obvious
+2. **Self-Documenting**: Names that immediately convey their purpose without documentation
+3. **.NET Alignment**: Consistency with established .NET framework patterns
+4. **Migration Safety**: Backward-compatible approach with clear phases
+5. **Future-Proof**: Supports evolution toward `IRunnable` interface
+
+The proposed terminology (`Application.Current` and `Application.RunStack`) provides immediate clarity while maintaining compatibility and supporting future architectural improvements.
+
+---
+
+**See also:**
+- [terminology-proposal.md](terminology-proposal.md) - Complete detailed proposal
+- [terminology-proposal-summary.md](terminology-proposal-summary.md) - Quick reference
+- [terminology-before-after.md](terminology-before-after.md) - Code comparison examples
+- [terminology-index.md](terminology-index.md) - Navigation guide
diff --git a/docfx/docs/terminology-index.md b/docfx/docs/terminology-index.md
new file mode 100644
index 0000000000..c5c3083867
--- /dev/null
+++ b/docfx/docs/terminology-index.md
@@ -0,0 +1,106 @@
+# Terminal.Gui Terminology Proposal - Documentation Index
+
+> **Updated October 2025**: Proposal validated and updated to reflect recent architectural modernizations, including removal of legacy MainLoop infrastructure, driver architecture refactoring, and test infrastructure improvements.
+>
+> **Latest Validation**: October 28, 2025 - Verified against current codebase including FakeDriver consolidation and recent API refinements.
+
+This directory contains a comprehensive proposal for renaming `Application.Top` and related terminology in Terminal.Gui v2.
+
+## 📚 Documents
+
+### 1. [terminology-proposal-summary.md](terminology-proposal-summary.md) ⭐ **Start Here**
+Quick overview of the proposal with key recommendations in a table format. Best for getting a high-level understanding.
+
+**Contents:**
+- Recommended changes table
+- Key benefits summary
+- Migration strategy overview
+- Quick code examples
+
+### 2. [terminology-diagrams.md](terminology-diagrams.md) 📊 **Visual Diagrams**
+Mermaid diagrams visualizing the proposal, relationships, and migration path.
+
+**Contents:**
+- Current vs Proposed terminology comparison
+- Stack relationship diagrams
+- Before/After naming patterns
+- .NET pattern consistency
+- View hierarchy and run stack
+- Usage flow examples
+- Evolution path timeline
+- Migration phases Gantt chart
+
+### 3. [terminology-before-after.md](terminology-before-after.md) 📝 **Code Examples**
+Side-by-side comparisons showing how the new terminology improves code clarity.
+
+**Contents:**
+- API naming comparisons
+- Real-world code examples
+- Documentation clarity improvements
+- Consistency with .NET patterns
+- Summary comparison table
+
+### 4. [terminology-proposal.md](terminology-proposal.md) 📖 **Full Details**
+Complete, comprehensive proposal with all analysis, rationale, and implementation details.
+
+**Contents:**
+- Executive summary
+- Background and current problems
+- Detailed proposal and rationale
+- Migration strategy (5 phases)
+- Proposed API changes with code
+- Benefits, risks, and mitigations
+- Implementation checklist
+- Alternative proposals considered
+
+## 🎯 Quick Summary
+
+### Recommended Changes
+
+| Current | Proposed | Why |
+|---------|----------|-----|
+| `Application.Top` | `Application.Current` | Clear, follows .NET patterns, self-documenting |
+| `Application.TopLevels` | `Application.RunStack` | Describes structure and content accurately |
+| `Toplevel` class | Keep (for now) | Allow evolution to `IRunnable` interface |
+
+### Key Benefits
+
+1. **Clarity**: Names immediately convey their purpose
+2. **Consistency**: Aligns with .NET ecosystem patterns
+3. **Readability**: Self-documenting code
+4. **Future-proof**: Works with planned `IRunnable` interface
+5. **Compatibility**: Backward-compatible migration path
+
+## 📖 Reading Guide
+
+**If you want to...**
+
+- 📋 **Get the gist quickly**: Read [terminology-proposal-summary.md](terminology-proposal-summary.md)
+- 🎨 **See visual diagrams**: Read [terminology-diagrams.md](terminology-diagrams.md)
+- 👀 **See concrete examples**: Read [terminology-before-after.md](terminology-before-after.md)
+- 🔍 **Understand all details**: Read [terminology-proposal.md](terminology-proposal.md)
+- 💡 **Implement the changes**: See implementation checklist in [terminology-proposal.md](terminology-proposal.md)
+
+## 🔗 Related Issues
+
+- **Issue #4329**: Rename/Clarify `Application.Toplevels`/`Top` Terminology (this proposal)
+- **Issue #2491**: Toplevel refactoring and `IRunnable` interface work
+
+## 💭 Feedback
+
+This proposal is open for discussion and feedback from the Terminal.Gui maintainers and community. Please comment on Issue #4329 with:
+- Questions about the proposal
+- Alternative naming suggestions
+- Migration concerns
+- Implementation details
+
+## 📝 Note on Implementation
+
+This proposal focuses on **naming and terminology only**. The actual implementation (adding new properties, deprecating old ones, updating documentation) would be a separate effort pending approval of this proposal.
+
+---
+
+**Created**: October 2025  
+**Issue**: #4329  
+**Related**: #2491  
+**Status**: Proposal - Awaiting Review
diff --git a/docfx/docs/terminology-proposal-summary.md b/docfx/docs/terminology-proposal-summary.md
new file mode 100644
index 0000000000..137b5be6c7
--- /dev/null
+++ b/docfx/docs/terminology-proposal-summary.md
@@ -0,0 +1,66 @@
+# Terminology Proposal Summary
+
+> **Updated October 2025**: Proposal validated against current modernized codebase (post-MainLoop removal, driver refactoring).
+> 
+> **Latest Validation**: October 28, 2025 - Confirmed accurate with recent driver architecture improvements and test infrastructure updates.
+
+This is a brief summary of the [full terminology proposal](terminology-proposal.md).
+
+## Recommended Changes
+
+| Current Name | Proposed Name | Rationale |
+|--------------|---------------|-----------|
+| `Application.Top` | `Application.Current` | Clear, follows .NET patterns (e.g., `Thread.CurrentThread`), indicates "currently active" |
+| `Application.TopLevels` | `Application.RunStack` | Descriptive of the stack structure, pairs well with `Current` |
+| `Toplevel` class | Keep as-is (for now) | Too disruptive to rename; allow gradual evolution toward `IRunnable` |
+
+## Why These Names?
+
+### Application.Current
+- ✅ Immediately understandable
+- ✅ Consistent with .NET conventions
+- ✅ Short and memorable
+- ✅ Accurately describes the "currently active/running view"
+
+### Application.RunStack
+- ✅ Describes what it contains (running views)
+- ✅ Describes its structure (stack)
+- ✅ Works with future `IRunnable` interface
+- ✅ Clear relationship with `Current` (top of the stack)
+
+## Migration Strategy
+
+1. **Phase 1**: Add new properties, mark old ones `[Obsolete]` (no warnings initially)
+2. **Phase 2**: Update documentation and examples
+3. **Phase 3**: Refactor internal code to use new names
+4. **Phase 4**: Enable deprecation warnings
+5. **Phase 5**: Remove deprecated APIs (future major version)
+
+## Example Code
+
+```csharp
+// Before
+Application.Top?.SetNeedsDraw();
+var focused = Application.Top.MostFocused;
+
+// After
+Application.Current?.SetNeedsDraw();
+var focused = Application.Current.MostFocused;
+```
+
+## Key Benefits
+
+1. **Improved Clarity**: Names that immediately convey their purpose
+2. **Better Readability**: Code is self-documenting
+3. **Consistency**: Aligns with .NET ecosystem patterns
+4. **Future-Proof**: Works with planned `IRunnable` interface
+5. **Minimal Disruption**: Backward-compatible migration path
+
+## See Also
+
+- [Visual Diagrams](terminology-diagrams.md) - Mermaid diagrams visualizing the proposal
+- [Full Proposal Document](terminology-proposal.md) - Complete analysis and implementation details
+- [Before/After Examples](terminology-before-after.md) - Side-by-side code comparisons
+- [Documentation Index](terminology-index.md) - Navigation guide
+- Issue #4329 - Original issue requesting terminology improvements
+- Issue #2491 - Toplevel refactoring and `IRunnable` interface work
diff --git a/docfx/docs/terminology-proposal.md b/docfx/docs/terminology-proposal.md
new file mode 100644
index 0000000000..0ba409f07b
--- /dev/null
+++ b/docfx/docs/terminology-proposal.md
@@ -0,0 +1,321 @@
+# Terminology Proposal: Renaming Application.Top and Toplevel
+
+> **Note**: This proposal has been updated (October 2025) to reflect recent architectural improvements in Terminal.Gui v2, including the removal of legacy MainLoop infrastructure, driver architecture refactoring (FakeDriver consolidation), and modernization of the application event loop. The proposal remains valid and relevant with the current codebase.
+>
+> **Latest Validation**: October 28, 2025 - Verified against recent changes including driver architecture improvements and test infrastructure modernization.
+
+## Executive Summary
+
+This document proposes new, clearer terminology to replace the confusing `Application.Top` and `Toplevel` naming in Terminal.Gui v2. The goal is to establish intuitive names that accurately represent the concepts while maintaining backward compatibility during migration.
+
+## Background
+
+### Current Problems
+
+1. **Confusing Terminology**: `Application.Top` suggests "the top of something" but actually represents the currently active view in the application's view hierarchy
+2. **Overloaded Meaning**: `Toplevel` is both a class name and conceptually represents views that can be "run" (have their own event loop)
+3. **Misleading Relationships**: `Application.TopLevels` (stack) vs `Application.Top` (current) creates confusion about plurality and relationships
+4. **Future Direction**: The codebase has TODO comments indicating a move toward an `IRunnable` interface, suggesting the current `Toplevel` class is transitional
+
+### Current Usage Patterns
+
+Based on current code analysis (as of October 28, 2025):
+- `Application.Top` - The currently active/running view with its own run loop
+- `Application.TopLevels` - Internal stack of all active "runnable" views  
+- `Application.CachedRunStateToplevel` - Internal caching mechanism for RunState management (added recently)
+- `Toplevel` class - Base class for views that can run independently (Window, Dialog, etc.)
+- Modal vs Non-modal - Views that can be "run" either as overlays or embedded
+
+**Recent Architectural Updates**: 
+- Terminal.Gui v2 has completed modernization of its application infrastructure
+- Legacy MainLoop code removed, consolidated around `ApplicationImpl.Coordinator`
+- Driver architecture refactored with FakeDriver consolidation into the main library
+- Test infrastructure modernized
+- The terminology confusion addressed in this proposal remains relevant with current codebase
+
+## Proposed Terminology
+
+### 1. Application.Top → Application.Current
+
+**Rationale:**
+- **Clarity**: "Current" clearly indicates "the one that is active right now"
+- **Familiar**: Aligns with common patterns like `Thread.CurrentThread`, `HttpContext.Current`, etc.
+- **Concise**: Short, easy to type, and memorable
+- **Accurate**: Directly describes what it represents - the currently running/active view
+
+**Alternative Names Considered:**
+- `Application.ActiveView` - More verbose, but very clear
+- `Application.CurrentView` - More explicit but redundant with property type
+- `Application.Running` - Could be confused with a boolean state
+- `Application.Main` - Misleading, as it's not always the main/first view
+- `Application.CurrentRunnable` - Too verbose, assumes future IRunnable
+
+### 2. Application.TopLevels → Application.RunStack
+
+**Rationale:**
+- **Descriptive**: Clearly indicates it's a stack of running views
+- **Technical**: Accurately represents the ConcurrentStack<T> implementation
+- **Paired**: Works well with `Application.Current` (Current from RunStack)
+- **Future-proof**: Works whether items are `Toplevel` or `IRunnable`
+
+**Alternative Names Considered:**
+- `Application.ViewStack` - Too generic, not all views are in this stack
+- `Application.RunnableStack` - Assumes future IRunnable interface
+- `Application.ModalStack` - Inaccurate, non-modal views can be in the stack
+- `Application.ActiveViews` - Doesn't convey the stack nature
+
+### 3. Toplevel Class → (Keep as-is with evolution plan)
+
+**Recommendation: Keep `Toplevel` class name for now, evolve toward `IRunnable`**
+
+**Rationale:**
+- **Too Disruptive**: Renaming would break every application
+- **Planned Evolution**: The codebase already has plans to introduce `IRunnable` interface (per TODO comments)
+- **Transitional**: `Toplevel` can become an implementation detail while `IRunnable` becomes the public interface
+- **Gradual Migration**: Allows for deprecation strategy rather than breaking change
+
+**Evolution Path:**
+1. Introduce `IRunnable` interface (future work, issue #2491)
+2. Have `Toplevel` implement `IRunnable`
+3. Update APIs to accept/return `IRunnable` where appropriate
+4. Deprecate `Toplevel` as a base class requirement
+5. Eventually, `Toplevel` becomes just one implementation of `IRunnable`
+
+**Alternative Considered:**
+- `RunnableView` - Better name but too breaking to change now
+
+## Proposed API Changes
+
+### Phase 1: Add New APIs (Backward Compatible)
+
+```csharp
+// In Application.cs
+namespace Terminal.Gui.App;
+
+public static partial class Application
+{
+    // NEW: Current API
+    /// <summary>
+    /// Gets the currently active view with its own run loop.
+    /// This is the view at the top of the <see cref="RunStack"/>.
+    /// </summary>
+    /// <remarks>
+    /// The current view receives all keyboard and mouse input and is responsible
+    /// for rendering its portion of the screen. When multiple views are running
+    /// (e.g., dialogs over windows), this represents the topmost, active view.
+    /// </remarks>
+    public static Toplevel? Current
+    {
+        get => Top;
+        internal set => Top = value;
+    }
+
+    // DEPRECATED: Keep for backward compatibility
+    [Obsolete("Use Application.Current instead. This property will be removed in a future version.", false)]
+    public static Toplevel? Top
+    {
+        get => ApplicationImpl.Instance.Top;
+        internal set => ApplicationImpl.Instance.Top = value;
+    }
+
+    // NEW: RunStack API
+    /// <summary>
+    /// Gets the stack of all currently running views.
+    /// Views are pushed onto this stack when <see cref="Run(Toplevel, Func{Exception, bool})"/> 
+    /// is called and popped when <see cref="RequestStop(Toplevel)"/> is called.
+    /// </summary>
+    internal static ConcurrentStack<Toplevel> RunStack => TopLevels;
+
+    // DEPRECATED: Keep for backward compatibility
+    [Obsolete("Use Application.RunStack instead. This property will be removed in a future version.", false)]
+    internal static ConcurrentStack<Toplevel> TopLevels => ApplicationImpl.Instance.TopLevels;
+}
+```
+
+### Phase 2: Update Documentation and Examples
+
+- Update all XML documentation to use new terminology
+- Update docfx documentation articles
+- Update code examples in Examples/ directory
+- Add migration guide to documentation
+
+### Phase 3: Internal Refactoring (No API Changes)
+
+- Update internal code to use `Application.Current` and `Application.RunStack`
+- Keep old properties as simple forwards for compatibility
+- Update test code to use new APIs
+
+### Phase 4: Deprecation Warnings (Future Major Version)
+
+- Change `Obsolete` attributes to show warnings
+- Provide clear migration messages
+- Allow several versions for migration
+
+### Phase 5: Removal (Future Major Version + N)
+
+- Remove deprecated APIs in a future major version
+- Ensure all documentation reflects new terminology
+
+## Migration Guide for Users
+
+### Simple Find-Replace
+
+For most code, migration is straightforward:
+
+```csharp
+// Old Code
+Application.Top?.SetNeedsDraw();
+var focused = Application.Top.MostFocused;
+
+// New Code  
+Application.Current?.SetNeedsDraw();
+var focused = Application.Current.MostFocused;
+```
+
+### More Complex Scenarios
+
+```csharp
+// Working with the view stack
+// Old Code
+if (Application.TopLevels.Count > 0)
+{
+    foreach (Toplevel topLevel in Application.TopLevels)
+    {
+        // process each running view
+    }
+}
+
+// New Code (when internal API is made public)
+if (Application.RunStack.Count > 0)
+{
+    foreach (Toplevel runnable in Application.RunStack)
+    {
+        // process each running view
+    }
+}
+```
+
+## Benefits of This Approach
+
+### 1. Improved Clarity
+- `Application.Current` is immediately understandable
+- `RunStack` clearly describes what it is and what it contains
+- Reduces cognitive load for new developers
+
+### 2. Better Code Readability
+```csharp
+// Before: What is "Top"? Top of what?
+Application.Top?.DoSomething();
+
+// After: Clear that we're working with the current view
+Application.Current?.DoSomething();
+```
+
+### 3. Consistency with .NET Patterns
+- Aligns with `Thread.CurrentThread`, `SynchronizationContext.Current`, etc.
+- Familiar to .NET developers
+
+### 4. Future-Proof
+- Works with planned `IRunnable` interface
+- `Current` can return `IRunnable?` in the future
+- `RunStack` can become `ConcurrentStack<IRunnable>` in the future
+
+### 5. Minimal Breaking Changes
+- Deprecated APIs remain functional
+- Gradual migration path
+- No immediate breaking changes for users
+
+## Risks and Mitigations
+
+### Risk 1: User Migration Effort
+**Mitigation**: 
+- Provide clear deprecation warnings
+- Offer automated migration tools (analyzers)
+- Allow multiple versions for migration
+- Provide comprehensive documentation
+
+### Risk 2: Third-Party Libraries
+**Mitigation**:
+- Keep deprecated APIs functional for extended period
+- Clearly communicate timeline in release notes
+- Engage with library maintainers early
+
+### Risk 3: Documentation Inconsistency
+**Mitigation**:
+- Systematic documentation update
+- Search for all occurrences in docs, examples, tests
+- Use automated tools to ensure completeness
+
+## Implementation Checklist
+
+### Core API Changes
+- [ ] Add `Application.Current` property with forwarding to `Top`
+- [ ] Add `[Obsolete]` attribute to `Application.Top` (warning disabled initially)
+- [ ] Add `Application.RunStack` property with forwarding to `TopLevels`
+- [ ] Add `[Obsolete]` attribute to `Application.TopLevels` (warning disabled initially)
+- [ ] Update XML documentation for new properties
+- [ ] Update IApplication interface if needed
+
+### Documentation Updates
+- [ ] Update all docfx articles mentioning `Application.Top`
+- [ ] Update API documentation
+- [ ] Create migration guide document
+- [ ] Update README.md if it mentions the old terminology
+- [ ] Update code examples in docfx
+- [ ] Update CONTRIBUTING.md and AGENTS.md if needed
+
+### Code Updates
+- [ ] Update all internal code to use `Application.Current`
+- [ ] Update all internal code to use `Application.RunStack` (where appropriate)
+- [ ] Update test code to use new APIs
+- [ ] Update example applications (UICatalog, Example, etc.)
+
+### Testing
+- [ ] Ensure all existing tests pass
+- [ ] Add tests for new properties
+- [ ] Add tests for deprecated property forwarding
+- [ ] Test that obsolete attributes work correctly
+
+### Communication
+- [ ] Update issue #4329 with proposal
+- [ ] Get feedback from maintainers
+- [ ] Document in release notes
+- [ ] Update migration guide from v1 to v2
+
+## Alternative Proposals Considered
+
+### Alternative 1: Application.ActiveView
+**Pros**: Very clear and explicit
+**Cons**: More verbose, `View` suffix is redundant with type
+
+### Alternative 2: Application.MainView
+**Pros**: Short and simple
+**Cons**: Misleading - not always the "main" view
+
+### Alternative 3: Application.CurrentTopLevel
+**Pros**: Keeps "TopLevel" terminology
+**Cons**: Doesn't solve the confusion about "TopLevel"
+
+### Alternative 4: Application.ForegroundView
+**Pros**: Describes visual position
+**Cons**: Could be confused with focus or z-order
+
+### Alternative 5: Keep Current Names
+**Pros**: No migration needed
+**Cons**: Confusion persists, misses opportunity for improvement
+
+## Conclusion
+
+This proposal recommends:
+1. **Rename `Application.Top` → `Application.Current`**: Clear, concise, familiar
+2. **Rename `Application.TopLevels` → `Application.RunStack`**: Descriptive and accurate
+3. **Keep `Toplevel` class as-is**: Allow for gradual evolution toward `IRunnable`
+4. **Phased migration**: Maintain backward compatibility with clear deprecation path
+
+The new terminology aligns with .NET conventions, improves code readability, and provides a clear migration path for users while supporting the future direction of the codebase.
+
+## References
+
+- Issue #4329: Rename/Clarify `Application.Toplevels`/`Top` Terminology
+- Issue #2491: Toplevel refactoring (IRunnable interface)
+- Current codebase analysis in Terminal.Gui v2_develop branch
diff --git a/docfx/docs/toc.yml b/docfx/docs/toc.yml
index 66c9b5cbbd..8acb4573f2 100644
--- a/docfx/docs/toc.yml
+++ b/docfx/docs/toc.yml
@@ -26,6 +26,8 @@
   href: events.md
 - name: Lexicon & Taxonomy
   href: lexicon.md
+- name: Terminology Proposal
+  href: terminology-index.md
 - name: Keyboard
   href: keyboard.md
 - name: Layout Engine