I remember running into this before but I can't find where to erase/fix the newly created config file. The way I understand it, if you access the jevent control panel from the child Joomla admin it will actually create a new config file somewhere which overrides any settings you set from that point forward on the parent jevents admin control panel.

Ive confirmed that the tables are set up correctly on the slave (views) and that the component is shared but my categories do not match. I can't figure out where this old date is being pulled from...

Which JEvents version are you using.
Is it the MVC or the old one.
Does the extension called "com_events" or the new name "com_jevents".
The config was in a file on disk in the case of "com_events".
Not in the case of "com_jevents".

Joomla 1.5.15
Jevents 1.5.2
JMS Multisites 1.2.16 | patches 1.2.22
The component is called com_jevents

My slave is showing a different outdated set of categories and I've confirmed in phpMySQL that the tables for my slave are view tables that link to the master jevent related ones.

somewhere there is a file that has been created or modified where the old categories are listed.

Jms Multisites does not touch to the JEvents (com_jevents).
Would you please provide a detailled scenario on how to reproduce your problem.
At the origin your question was related to the location of the "config" in jevents. It is located in the DB.

I have determined that there is data related to jevents that is stored in the database in addition to the tables that multisites sets up as views

category data is stored in the standard joomla category table with a section name of _jevents and it doesnt show up in the admin interface. That data is hidden from the joomla admin tool.

As a result, the information stored in the master category table is replicated to the children upon their creation, but if you then edit a category in jevents later, the children never get the update.

Sorry, I don't have any solution for that fpr the moment.
As you seems have analyzed in detail this case, would you please give us more detail on the source and line that may use that.

If this is true, we will remove JEvents from the sharing definitions because this also mean that the category id could be stored somewhere and could be different depending on the slave sites.