I prefer to look at unfixed defects as simply additions to scope. If a defect is not related to work currently ‘in progress’, then a change to the system needs to be made to correct the defect. This is analogous to a new story (traditional scope) that requires a change to be made to the system to implement it. In both situations, you can estimate and track in the same way, and they both affect the overall amount of work required to deliver a ‘completed’ project in the same way. This also allows the business to prioritise when a defect gets fixed (if at all), the same way they do with new stories.
This is different from technical debt, which is not normally captured as discrete, independent work to be completed. Attempting to recover technical debt is usually considered when implementing any story that affects the area of code where the debt has been incurred.
I’d like to experiment on a project by tracking defects-not-related-to-current-stories as ‘discovered scope’ (whilst clearly flagging that it is scope caused by a defect rather than a new feature).