The reason this is happening is because the Private files page (and other pages using the user context) do not use the function $PAGE->set_blocks_editing_capability so the capability used by default is 'moodle/site:manageblocks'. Where as on the My Moodle page it specifies $PAGE->set_blocks_editing_capability('moodle/my:manageblocks') which allows users to add blocks on this page. Students do not have the capability 'moodle/site:manageblocks' by default, so on the private files page the student can not add blocks. However, an administrator does. Once this capability has been confirmed, another check on each individual block to see if it can be added is performed. With the previous logic in the function user_can_addto it was comparing the context to see if the user was on the My Moodle page. This if statement was then entered for the private files page as it uses the user context. With the introduction of the new capabilities it would then check 'moodle/my:manageblocks' and the 'myaddinstance' capability for the blocks, but the block capability was removed for these blocks (see MDL-34270) as they can not be added to the My Moodle page, which causes the debugging errors.

The fix was to perform a check on the page type to ensure we are indeed on the my-index page before we perform the myaddinstance capability check.