Thanks for filing these @Etonkovidova! Kirsten and I agreed that (2) and (5) should be top priority to fix. If (3) is an easy fix, then that would be great too (so this probs needs Engineering input)

I'm trying to take action on this issue but the variety of observations and expectations is tricky. An important disclaimer is that the comparison table on the description is comparing two different views in the full screen pictures. On the left the view shown is what we call the mobile details view whereas on the right the view shown is the mobile overlay. Users can end-up accessing one or the other depending on how fast the Javascript of the mobile summary view loads. This might seem confusing but is implemented in this way so users without Javascript enabled or very old browsers still get something rendered on the screen. While we may want to give some level of support to this user niche, there was some team consensus on removing this view (and just inform users without Javascript enabled or old browsers with a message "Please enable JavaScript to view this component"), see T264992: Remove mobile-details mode from Special:Homepage.

As I understand the current status, the comparison table for "old impact" vs "new impact" fullscreen mobile views would look as follows:

View/Module	Old impact	New impact
mobile summary (scrolled)
mobile details
mobile overlay

All screenshots taken from en.m.wikipedia.beta with abrowser simulated iPhone6 resolution 375px x 667px

In regards the observations:

1. Old mobile screens are short, the WP header + the "Hello Username" heading + an eventual banner + the "add email" module consume half of the screen. There's room for improvement but unclear what's the expected outcome from the task description, I would consider opening a dedicated issue if we find it relevant and involve design.
2. I'm failing to reproduce the issue in beta enwiki and testwiki registering a new user, could we specify more the steps to reproduce? And maybe re-open T330692: Impact Module: don't show "Updated design" info drawer to new users since it seems a regression on that issue.
3. The screenshot shows definitely something wrong since the footer should be fixed to the bottom. There are some known issues for Android 4-4.3 but I don't think our case is hitting one of these, I will investigate forward.
4. Isn't this expected behavior as mentioned in (3)?
5. This is a known gap from our Vue custom implementation of the tooltip component, there's not overflow control at all. I filed an internal task T339106: Add overflow control to CPopover component so we can provide a quick fix for "new impact". The ideal scenario would be to have a Codex component which has overflow control.

Thanks for investigating these issues, @Sgs !

I just tested several different scenarios and I can't replicate #2 either. As far as I can tell, this issue was resolved.

Given that you've added a separate task for resolving #5, and the Acceptance Criteria for task only asks for fixes for #2 and #5, I think you can resolve this task (or move to QA if you want to give @Etonkovidova a chance to replicate #2).