Raid1 question
Solution 1:
The two answers about it being marked failed and rebuilding are correct, and hopefully this is what will happen. That's the best-case scenario.
The other possibility is that the software does not notice, and then it'll still think the drives are in sync. (For example, this could happen if you did this stunt with the power off) The end result will most likely be corruption, and the only fix will be to format and restore from backup.
Remember, RAID works at the disk level, it doesn't know anything about the filesystem on top. Just a bunch of sectors. When the filesystem requests block 10, the RAID layer knows that block 10 is stored on block 10 of both disk1 and disk2. Somehow, it picks one disk or the other and reads block 10. Except because of your modifying the disks behind its back, block 10 on disk1 and disk2 is different. Oops. You can expect a mix of disk1 and disk2 on a per-block basis, including blocks used to store filesystem metadata.
Fixing the mess
I suggest your best bet to recover from this, given that format and restore from backup is not an option:
(a) Immediately image both drives. Backups are important. Optionally, you may want to only work on the copies.
(b) If the array has not been in read/write mode after this mistake, just pull the modified drive. Rebuild with a new, blank drive.
(c) If the array has been in read/write mode, pick a drive and drop it out the array. Rebuild onto a new drive.
(d) If you completely don't care which drive, just (replacing X with your array number, of course): This forces a resync.
echo repair > /sys/block/mdX/md/sync_action
(e) Force a fsck on the now rebuilt array.
(f) Do whatever you can to verify your data. For example, run debsums to check OS integrity, supplying all needed package files for things that don't have MD5 sums.
Note that the drive needs to be blank, or at least all RAID info wiped from it, otherwise the rebuild won't work right.
Solution 2:
When you disconnect a drive from an active RAID array, it will see the drive as failed within its configuration. When you insert a new drive (or the same drive), it will see it as "new" to the array and rebuild the contents from the known good remaining drive, so any changes you made to the contents will be overwritten. If you do this to a drive while the array is offline, the changes you made will upset the checksums that the array controller uses to track changes, and again, it will see the drive as failed and attempt a rebuild.
If you want to copy files into your array, you'll need to do so through the controller (regardless of whether it's software or hardware).
Solution 3:
Is this a Linux or Windows question? What is your specific implementation?
Usually, the removed drive is failed, and when adding it back, you'll have to "unfail" it. This in turn usually means that the failed disk is re-initialized with all the data from the working disk. So in essence, all the changes made to the disk you removed will probably be lost in such a situation