Weekly Retro

That depends on the context, however, we could oversimplify that any change introduce interruption. Here some insights from the Scrum Guide that may help you to find an answer:

In current version of the Scrum Guide, adding identified improvement to the Sprint Backlog is rather considered as useful practice, than strict rule to follow. General rule is to address them as soon as possible.

The Scrum Team identifies the most helpful changes to improve its effectiveness. The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint.

If I understand you correctly, you still have 2 weeks Sprints, but you have introduced extra Sprint Retrospective a like event mid-sprint -> therefore you have “retro” on weekly basis. Regardless of potential value of such practice, if you add something to the Sprint Backlog, you, as a whole Scrum Team, should remember that:

During the Sprint no changes are made that would endanger the Sprint Goal

So even if it is interruption, you should assess it by impact on your ability to achieve the Sprint Goal. IMHO If it will put it in danger, then you should rather wait and address that improvement “as soon as possible”.

Here is another guidance in that direction:

If any aspects of a process deviate outside acceptable limits or if the resulting product is unacceptable, the process being applied or the materials being produced must be adjusted. The adjustment must be made as soon as possible to minimize further deviation.

However, there is also one asterisks to bear in mind:

A Sprint could be cancelled if the Sprint Goal becomes obsolete. Only the Product Owner has the authority to cancel the Sprint.

I can imagine a scenario in which by addressing identified improvement you put Sprint Goal in danger, and by not addressing it you render the Sprint Goal as not acceptable, maybe even obsolete due to i.e missed deadline by that. Therefore Scrum Team may decide to either accept risk/danger and introduce that improvement. Or they may influence the PO who can decide to cancel the Sprint.

Another guidance you may find in the Scrum Values:

The Scrum Team and its stakeholders are open about the work and the challenges. S (…) The Scrum Team members have the courage to do the right thing, to work on tough problems.

Hope this helps 🙂

Now, what if we switch to WEEKLY Retro, 

Is there a compelling reason to have 2 Retrospectives in a 2 week Sprint?  What does the team hope to gain from it?  

The section of the Scrum Guide that describes the Retrospective clearly states the Retrospective concludes the Sprint and references "the last Sprint" as the focus of the event. 

I have never worked with a team where multiple Retrospectives were needed so I can't say if I think it is a good idea or not.  I do think that any team the is supportive and motivated by the Scrum Values will usually be comfortable voicing concerns at any time and not waiting for a specific timed event to do so.  The Retrospective provides a time allocated to focus entirely on the team's ability to work together.  But much like refinement, I don't think it has to be done only at that time. 

Now, what if we switch to WEEKLY Retro, because if we add the identified experiments/ action items to CURRENT Sprint Backlog then will it be considerred as INTERRUPTION ?

Never mind. If you've identified them as experiments or action items for this Sprint, presumably they must be worth doing. In other words, presumably the team will have planned them in because they'll help the Sprint Goal to be better met.

If I was working with this team, I'd take a middle ground between what Ian and Daniel already said.

At a Sprint Retrospective, the team decided that it may be a good idea to meet in the middle of their Sprint to inspect how their improvements are going and make sure that things are working well, and to make changes more frequently than the end-of-Sprint Sprint Retrospective. Scrum is good for these kinds of experiments because they can be timeboxed. The team can try this experiment for a couple of Sprints and then talk about it at a later Sprint Retrospective to see if it's worth continuing. The team can always revisit at any earlier Sprint Retrospective if they need to. The worst case scenario is that the team needs to account for this extra time when carrying out Sprint Planning, which would reduce the team's capacity for work and would be reflected in the Sprint Goal and Sprint Backlog.

Personally, though I'm not seeing the value in this. Maybe it's because I'm not there on the team, but the Sprint-cadence for retrospective and improvements has always been more than sufficient in my experience. The Daily Scrum is a good place to check in on improvements to the team's way of working, to make sure that the team is making progress against both the Sprint Goal as well as any improvement initiatives. The Daily Scrum is also a reasonable place to raise impediments or problems early, without necessarily waiting for the Sprint Retrospective.