A cloud-based service included in Microsoft 365, delivering scalable messaging and collaboration features with simplified management and automatic updates.
This is normal behavior from your description. The old database had 1 name the new database had another. The database name is part of the metadata for the message. So you created an empty mailbox, restored from backup, which put 1 copy of a message into the new database and restored from pst which put another copy in. So either 1 of 2 things happened. First veem backup/restore was being helpful by changing the name of the metadata to the new name during it's import and the import from pst via powershell was not, so the server saw these as not duplicates. Second, veem restore didn't change the metadata of the database name, but the outlook pst file didn't have the database name in it's metadata and so the powershell import added the new database name as part of the metadata.
The basic takeaway here is you cannot trust imports/exports from psts from either different sources or using different tools to not gracefully handle conflicts. The most common example often cited is importing a pst file created by powershell export on an old mailserver to a new mailserver, then importing a pst created by export from an .ost file into a .pst file that covers the same date range. Remember that the .pst file format has never been "officially" documented by Microsoft, and the only 2 known tools out there that create .pst files are Outlook, and the API's within exchange that are used by some backup/restore tools that have the capability of restoring from backup into a pst, and by the powershell import/export commands. All the backup/restore tools I have ever seen that can "create" pst's depend on hacks like loading outlook on the machine you are running the backup restore tool from or having an exchange server somewhere (such as the target) so they clearly are using APIs inside of Outlook or in Exchange to create the PST