Depending on your needs, you may be able to just create the related record using the relationship option of 'Allow creation of Record'.
Otherwise, you should be able to reduce this script as well.
Set Variable [$PT_ID; Value: Pts::ID]
If [ IsEmpty ( imnRecord:: PT_ID ) ]
Go to Layout [ "imnRecord" ( imnRecord ) ]
Set Field [imnRec:: PT_ID;$PT_ID]
Commit Records/Requests [ ]
Im not sure if i understand or explained myself correctly,
I have 2 tables, "Pts" and "imn". These are related through PT_ID.
Using a layout based on the "Pts" table I create a new record for a new Patient. I then have a Navigation Button that takes you to a layout based on "imn" and creates a new record with the PT_ID number.
Next time i look at that patients record and click the button it should go to the "imn" layout and look for that patients related record.
will the script you provided do all this.
i might be wrong but do you not need to perform a find for this?
I ran a series of tests and found the problem lies in the find request. while it works fine on the Mac the windows pc comes up with no records found.
Find request is as follows
imn::PT_ID Criteria is $PT_ID,
Does windows not recognize the variable?
Windows will recognize that variable just fine.
If you are using a reference to a variable in the criteria that's part of this step:
Perform Find [Restore]
I don't see how that would work for mac or windows.
The script checks to see if there is a valid related child record. If it does not exist, it goes to the child layout and creates a new record.
I agree with Phil.
I'm not sure how you are performing a find on Criteria $PT_ID as perform find doesn't work with variables even on the mac platform...
at least in 10 and earlier unless I missed something.
I would suggest a slight modification to your script so that you enter find mode and set the variable then perform the find without a criteria.
Set Variable [$PT_ID; Value:Pts::PID]
Go to Layout ["imnRecord" (imnRecord)]
Set Error Capture [On]
Enter Find Mode
Set Field [Pts::PID; $PT_ID]
Perform Find 
Set Error Capture [Off]
If [Get (FoundCount) = 0]
Set Field [imnRec::PT_ID;$PT_ID]
Commit Records/Requests 
In the bigger picture though, I believe that Mr. Vodka is right it would be faster and better to go through the relationship. The less script steps ( as well as unstored calculations, summary fields, etc) you have, the better performance you will have in your database.
Allow creation of related, suggested by Mr. Vodka, would be the best way to go if you have a current relationship established as:
Value:Pts::PID = ImnRecord::PT_ID
Just set the related PT_id with the parent PID. You don't even need to find out if there is already one. If your relationship is only on the ID, it won't hurt if there's a related record and if there isn't, it'll create one. And no need to perform a find either. The only reason you might want to test IsEmpty ( ImnRecord::PT_ID ) is because if you set the ID again and it exists, it will update the modification timestamp.
But something looks off and I have to ask ..
Do you happen to have two table occurrences of your ImnRecord table? One called ImnRecord and one called imnRec or is that just a typo? Because if you try to set a field on the "imnRecord" layout (which is based upon imnRecord) and you use (in your script) the step:
Set Field [imnRec::PT_ID;$PT_ID]
... it would fail (unless imnRec and ImnRecord are related). If Error Capture happens to be on then you won't even receive the message telling you that it can't complete the operation because the field you are attempting to set isn't part of the related record.
And yes, we can use variables in Find Requests in vs. 11 and that part should work (I haven't tested it in either OS yet). I would think we would have heard on several forums if it was broken but that is just a guess.