The simple answer is that this is by design. The detail as to why follows.
Full Access and Send As
The Full Access and Send As permissions are stored on the AD User account.  More specifically, the Full-Access permission can be seen on the LDAP property ‘msExchMailboxRights’ and the Send-As permission can be seen on the security details of the user account itself.  Full Access permissions are considered a “mailbox permission” and Send-As is considered a “user permission”.  This distinction stems back to a change that happened during the life-cycle of Exchange 2003.
The fact that these permissions are stored and managed on an AD user account mean that the use of the permission depends upon the domain in which the user authenticates.  If a user authenticates to Domain-A, then only accounts and groups in Domain-A will work to access the mailbox.  In a cross-forest migration scenario, this becomes problematic unless some thought and unique execution is performed.
In a cross-forest migration, there is often a desire to provide Single-Sign-On for end users in order to make the transition be as low-impact as possible.  Microsoft Exchange has supported a feature of this ability since Exchange 2000 and it is now known as “Linked Mailboxes”.  This feature allows Exchange to accept the authentication that occurs in a remote domain to be used to access a mailbox.  However, the side effect of this is that authentication is occurring in the source domain (Domain-A in the previous description).
Since authentication is occurring in the source, source accounts and group must then have rights to target mailboxes and exchange objects.
In order to provide this facility, the migrator will simply pickup the currently listed permissions on a source mailbox and place them on the target mailbox.  The result is that Domain-A\username is listed on the mailbox in Domain-B.
Not Using Linked Mailboxes
If a cross-forest migration is to occur without the use of Linked Mailboxes, then the context of authentication changes.  If users are still logging on to the source domain, they will be prompted by Outlook to access the target mailbox.  The credentials then would have to be from the target domain:  Domain-B\username.
This causes the authentication to be from the target domain and as such target domain objects are needed to access target resources – the opposite of Linked Mailboxes above.
This can also happen if a user account migration occurs before the mailbox migration, such that users begin logging in to the target domain prior to the mailbox migration.  The result is the same:  authentication is occurring in the target domain.
Considering how the migrator handles Full-Access and Send-As permissions, it should be seen that, on the surface, there could be an issue.  Priasoft will set Domain-A\username to have permission to a mailbox in Domain-B, but authentication is occurring in Domain-B and then doesn’t match the permission set on the mailbox.
SID History
The resolution to the above issue is with the migration of the SIDs of the source accounts and groups.  When the context of authentication is in Domain-B (the target domain), when the user Domain-B\username attempts to access a mailbox, that user will have 2 SIDs with which to try to gain access:  the primary SID from the target domain and the original SID from the source domain.  Through this mechanism, the Domain-B\username user will be able to access the target mailbox even though Priasoft only set the account from the source domain.