No, tt's not the problem.
Yes, that is the problem. It may not be the only problem, but it most certainly is why "the data in the first group you added has vanished".
You have created your repeat group by making a repeated join in the list from subjects_classes.id to progress_report.subject. Which means that progress_report.subject needs to be an integer field, which contains the id (primary key) of subjects_classes. The join query generated looks like "LEFT JOIN progress_reports ON progress_reports.subject = subjects_classes.id".
But then in your form, progress_reports.subject is a CDD which you have configured to store the "Subject" (text) not the "id".
This will not work, and will cause all kinds of crazy things to happen when you create, save and edit repeat groups, as you have told Fabrik you are joining those two tables with the 'id' as foreign key, but then you are saving them using something else.
First thing, the Subject element on progress_reports needs to store the "id (RECOMMENDED)" (all caps added for emphasis). In both the original (parent) group/form, and any copies of it.
Second thing, when used in that repeat group on the Student Reports form, it shouldn't be an editable CDD. It should be a hidden field set to "integer". That is the FK element. Fabrik knows which "parent" you are adding that repeat row to (the row for the main table, i.e. the form's rowid), so will automatically set it. In other words, if you are adding a new report to the "Agriculture" form, we know what the "subject" in the repeat needs to be. And Fabrik has to manage it's own foreign keys, otherwise, as we can see, things go wobbly.
This will no doubt have consequences on how your CDD's are set up, and I suspect that's why you elected to use the "Subject" rather than the id.
-- hugh