Unfortunately the FileSystemWatcher (FSW) is a pain to deal with in a compiled language and PS is going to make it that much harder. File system events don't work like you might think they do. You can google for all the discussions as to why.
The net take away is that FSW events will get raised before you can actually do anything with the file in many cases and there is nothing you can do about it. Assume that you have a process P that is going to create or write to a file (there is no difference). P tells the file system to copy a file to some directory that you're monitoring. Depending on a variety of circumstances this could trigger a create and multiple update events or just a create event. The events occur as part of the call that P made so your code is getting called potentially before P even returns back from its call. Depending upon what you intend to do with the file and how P is interacting with the file there is a good chance P will still have a write lock on the file and therefore you won't be able to read it. There is no event to know when P has released its lock.
The first challenge with FSW is that you cannot really do anything in the actual event handler. Firstly it is happening as part of a larger request and therefore needs to be fast. Secondly the other process still likely has the file open and may still be writing to it so you have no way of knowing what the state of the file is. In most implementations I've seen work, people push a notification to a queue that the event occurred and have a background thread running that then attempts to access the file and do the work periodically. Of course that background thread may not be able to do the work (because of locking) or may actually get notified multiple times (because a single write to a file can trigger multiple change events). So it can get tricky. You would need to deal with this in your PS script as well. The threading is the more difficult part as you'll have to have a queue that you monitor.
The second challenge, as already mentioned, is that a single FS action can trigger multiple events. If the file is small you may just get a single create event. If it is large or the other process is writing it in chunks then you may also get one or more change events. Your watcher has no way of knowing what will happen and therefore when it is safe to proceed. There is no good solution here and is dependent upon what you are trying to do.
Honestly I would try to solve this issue by looking at how I'm calling the thing that produces the file. Worst case is polling but even that can be problematic.