For what you're looking for you'll need to find a way to either 1) convert over to a many to many relationship and use the table structure to support what you're doing or 2) keep what you're doing and using Pipelines or some other method to convert the multi select over to a many to many.
What you're trying to do and any potential updates you want to do for reporting and tracking will need the relationship to join the employee to a presentation no matter how you slice it.
If you keep it pretty simple - I would suggest replacing the multi select with an embedded grid-edit report. So if you're on a presentation record for example - you can create the intermediary join table and have an embedded grid edit where the only column is 'Employee' and you pick their name in a dropdown. You can replicate that for Reviewers. Or if you're on an employee record an embedded grid edit of presentations.
If you REALLY want to keep the traditional multi-select, you could evaluate using a Pipeline and loop through the list of employees that are included the the multiselect and create a new record in your intermediary table for each employee. This allows you to keep the UI of the multi select but gain the benefit of the proper structure. I would caution here though that if you add/remove people you need to be checking to see if that person already exists or should be removed so this gets hairy quickly, hence the recommendation for the embedded grid edit above.
In your comment you mention a rich-text to parse out the names and make links which is doable - but that link is purely going to be navigation and anytime you need to do something different such as set up a report, make a notification/reminder or anything specific to one employee you'll hit a wall which is why I wouldn't recommend it.
Thanks, Chayce. I hadn't considered making the reports directly editable through grid edit, but that is a good thought and would serve the purpose here, if not the cleanest looking. Was hoping there might be a cleaner solution that I wasn't seeing but I had many of the same thoughts you mention about the challenges with each of the different options. Good points on the need for additional maintenance/checks if we do pursue the multi-select approach.
If you're comfortable with playing with your own primary keys, you could try the multi select route but when you create the records you make the primary key something like [Employee Email] - [Related Presentation]. You can then add an 'Applicable' flag that you pull the lookup of the multi-select and bring that down to use a Contains function to see if that persons name still appears in the list of employees presenting. This alleviates having to worry about only creating certain people or deleting them because then you can just filter out the ones that aren't applicable.
I tend to agree the user experience of the multi select is typically better for the everyday user. The above is still the more complicated route than inline grid edit but an option nonetheless.
