You have some odd steps here
Set Variable [$$CurrentType ; value: Members::Type]
Set Field [Members::Type ; $$CurrentType]
makes no sense. But it also does no harm as it only sets the type field to the value it already has.
Nothing jumps out as obviously wrong here. Is the current layout a layout based on the Members table occurrence?
When you say that you can "watch" it, does that mean that you are using FileMaker Advanced's Script Debugger to step through the script?
FYI, there is a calculated special function that kicks in when I set field.
Out of frustration I started trying things that I knew 'would not work'.
Background: I have 2 windows open: Setup and Membership.
The portal row that is deleted is in Setup.
The script (as you can see) does a Select Window (Membership)
Apparently that does not matter: When I manually executed a Close Window (Setup) after deleting the portal row, everything worked.
Do you have any ideas as to 'why'?
Just an idea, and I'm not sure how the ValueExists() works, but is it possible that when you deleted the membership type for Brown you replaced it with a space instead of an empty field.
Each members::Type is derived from a field in a Setup::Type portal.
The phenomena occurs when I delete a Setup::Type portal row.
What should happen is that any Member record would now have a TYPE that is NOT a valid type (it is orphaned). In this situation, *ALL* members who have a Members::Type that is not in the 'new' Setup:Type list are invalid and should have their Members::ValidType field set to 0 (zero).
Leaving the Setup Window open (and using Select Window (Membership) causes the problem.
Closing the Setup Window immediately AFTER deleting the portal row causes the script to act as expected.
The question is "Why?"
Maybe you need a Commit record to take place before you switch windows. If you open a record for editing in one window, you cannot edit the same record in another window. You will be locked out just as though two users were trying to edit the same record in a file shared over a network. Normally, this produces an error message unless Set Error Capture[on] is used to supress it. I haven't suggested this earlier because I didn't know about the other window and I don't see that step in your script.