Generically, a backlog is a project or product management artifact that represents potential future work. As such, it's most useful to think of it as a register of future work within the project rather than as a top-level status or a container of work states.
I provide additional detail below on what backlogs are, how to conceptualize them as planning artifacts, and how to visualize them within the scope of a project. However, if you just want to see how an experienced agilist visualizes them and compare that to the hierarchies in your original question, you can skip directly to the last section without the intervening explanations.
What an Agile Backlog Is
I can't tell by definition...[if a backlog is] a status of an item or the collection of all items (no matter the status).
A backlog is really just a bucket of items that are not yet work-in-progress. These items might be incoming requests, to-do items, or actively planned work, but whether or not they are ordered by some metric such priority, value, lead time, FIFO, or something else is generally framework-specific.
In Scrum, for example, the Product Backlog is generally a list of items grouped into cohesive Increments that are then placed into some sort of ordered list by priority. "Priority" is not explicitly defined by Scrum, allowing for priority to be determined by the current needs of the business and the practicalities of the project, except to define it as ordinal and set by the Product Owner. Other frameworks (and even other types of backlogs such as the Sprint Backlog) can and do treat the contents and ordering of backlogs a little differently.
While backlog items can carry metadata (e.g. value, cost, or priority), actual item statuses like "in progress" or "done" aren't among them. If they were tracked that way, they shouldn't be left in the backlog in the first place, as items that are in-progress or some other status (even "blocked") are really work items that are either in-scope for the current iteration or actively work-in-progress.
How to Think of Agile Backlogs
In an agile context, a backlog is a collection of potential work items, primarily used as a place to hold future work. You could certainly partition a backlog in a MoSCoW sort of way, add metadata about how items got there (e.g. as customer requests or as necessary architectural runway), or add other information about its relative value or priority. However, a backlog (especially a Scrum Product or Sprint Backlog) shouldn't really be a perpetual parking lot. From an agile perspective, saying something is basically a "never going to happen" but dragging it along in your Product Backlog forever is an anti-pattern, but you theoretically could.
Having a separate "parking lot" for low-priority items or non-starters is not something addressed by the current Scrum framework, but it's not an uncommon practice when you want to differentiate "future work" from things that are deemed out of scope. However you decide to handle such items, an experienced agilist probably wouldn't consider them backlog items since they aren't really things that are likely to become actual work items.
Since the backlog is intended to be a project/product management artifact or future-work register rather than a work-in-progress state tracker, I think most of your confusion about it would disappear if you simply reframe the use case for the backlog or change the terminology you're using. I recommend that you think of it as a future-work register or project artifact rather than the status of a work item. When you do that, it becomes self-evident that the backlog (whether Product Backlog, Sprint Backlog, or some other form of backlog) is really an incoming stage for applying selection criteria before something becomes a to-do item. In other words, it's the sorting bucket for prioritization and forward-looking product planning rather than a list of what's currently in scope right now.
Since agile frameworks are generally based on pull-queues and incremental, iterative, or just-in-time planning, the backlog is where things are held until they are in scope for a near-term increment or ready to be pulled into the work pipeline. At that time, they would be removed from the backlog and into a Sprint Backlog, To-Do column on a kanban, or placed into the appropriate work-in-progress bucket representing the current status or pull-queue for the given work item.
Visualizing Backlogs as Part of the Project Hierarchy
Without using the term "backlog" directly (although I've mentioned where certain things fit within Scrum's two backlogs for comparison) you might visualize the purpose and utility of backlogs like this:
- PROJECT (a finite process to develop, build, or deliver something)
- Planning Artifacts
- Future Work Items (in Scrum, this is the Product Backlog)
- Lower-Priority Work Items (in Scrum, these are generally unrefined epics for the more-distant future)
- Near-Term or Upcoming Work Items (in Scrum, this is the stuff addressed in Backlog Refinement)
- Immediately In-Scope Work Items (in Scrum, this is the stuff addressed during Sprint Planning)
- Currently In-Scope Work Items (in Scrum, this is the stuff pulled into the Sprint Backlog from the Product Backlog to meet the current Sprint Goal defined during Sprint Planning)
- In-Scope Work Items (in Scrum, this is the current Sprint Backlog that meets the Sprint Goal and collectively delivers the Increment)
- Ready-for-Work Items (the current iteration's pull-queue; often the Sprint Backlog itself, or a To-Do column in Kanban)
- Work-In-Progress Items (can be represented by multiple states; basically any active status your processes require including Development, QA, Review, or any other activity needed to meet the Definition of Done)
- Done (in Scrum, this is the stuff that would be demoed or deemed delivered during the Sprint Review; however, in continuous delivery or continuous deployment environments it may actually already have been "delivered" if required by the Definition of Done)
In agile frameworks, backlogs are planning artifacts, while statuses are applied to work-in-progress items. The top-level item is the project, not a backlog, and there can be multiple backlogs to represent pull-queues for various activities.