When new information exposes issues with the current piece of work in a sprint, you discuss it, and then change whatever part of the plan no longer makes sense given the new information.
Will it mess up the numbers? Absolutely, but only for that piece. And as a result of the change of plans being entered into the current sprint (with something perhaps bumped to make room, or maybe the work itself bumped to a later sprint to give more time to plan for the new challenges) you already have a new estimate. And you have a paper trail of what happened and how you dealt with it.
Your velocity goes down and you lose some predictability, but your agility goes up because you can adjust instantly to new challenges. None of these tools are a panacea; you have to thoughtfully decide which trade-offs will offer the greatest benefit for your particular project.
The "deadlines" shouldn't be thought of as hard deadlines. They're estimates of what you expect to have done at the end of some arbitrary period. Your accuracy in this should be measured statistically over time. If it turns out that you're consistently under or over, you adjust how you estimate. Ideally you want your estimates to average out to break-even over the course of a year. The point isn't to be able to determine exactly how much work you'll do, but rather to determine with a high degree of confidence (80%? 90%?) when the work will be done, with the understanding that it's not guaranteed (i.e. it's a point statistic). It's a planning tool, not a performance measure (the moment you treat it as a performance measure, it becomes useless due to the cobra effect).
Flexibility is good. I agree with that approach. But then I fail to see the benefit in scrum in the first place. The other things you mentioned (measuring all these metrics) does not seem helpful to me at all.
When you can measure metrics with some reliability, your executive team can use those metrics to plan out releases (e.g. "the new Fizzbuzz feature is expected in Q3"). That allows your marketing team, budgeting team, and deal flow team to plan around it (with the understanding that it is statistically reliable, not necessarily individually reliable).
If your development situation has high enough stability that kanban will be the best fit, you'll get much more reliable metrics for planning, but less flexibility when something unexpected happens.
If your development situation has enough uncertainty that scrum is the better fit, you'll have less reliable metrics for planning, but a lot of flexibility to deal with the unexpected (which you expect to encounter with some frequency, otherwise you'd be using kanban).
Cutting edge technologies and startups are usually better suited to scrum because they need the flexibility to pivot when needed. Well established technologies (like Oracle DB or MS Office or Ubuntu or Jira or a CRUD app) are likely better suited to kanban because they'll benefit from the streamlining at the cost of flexibility they don't need anyway.
Have you tried to just track time on board / time on column on each task on Kanban board?
You just need to keep track of time to trigger those discussions.
You can technically do everything with both tools, but each is optimized for a particular situation. They're so closely related that many people think of them as competing alternatives rather than as situational alternatives.
Will it mess up the numbers? Absolutely, but only for that piece. And as a result of the change of plans being entered into the current sprint (with something perhaps bumped to make room, or maybe the work itself bumped to a later sprint to give more time to plan for the new challenges) you already have a new estimate. And you have a paper trail of what happened and how you dealt with it.
Your velocity goes down and you lose some predictability, but your agility goes up because you can adjust instantly to new challenges. None of these tools are a panacea; you have to thoughtfully decide which trade-offs will offer the greatest benefit for your particular project.
The "deadlines" shouldn't be thought of as hard deadlines. They're estimates of what you expect to have done at the end of some arbitrary period. Your accuracy in this should be measured statistically over time. If it turns out that you're consistently under or over, you adjust how you estimate. Ideally you want your estimates to average out to break-even over the course of a year. The point isn't to be able to determine exactly how much work you'll do, but rather to determine with a high degree of confidence (80%? 90%?) when the work will be done, with the understanding that it's not guaranteed (i.e. it's a point statistic). It's a planning tool, not a performance measure (the moment you treat it as a performance measure, it becomes useless due to the cobra effect).