Let's look at the fork from theoretical POV, not practical implementation.
When developer puts fork in code, he supposing that execution will
spawn another, parallel process:

          /-------- original process
---------
          \-------- spawned fork

--------> time

Suppose, in ideal environment both processes start running in
parallel, and there is no scheduling, preemption and another gory
details.

So, it's obvious: if you need some state to be consistent in both
execution threads, you should make sure to initialize it before fork
happens.

Andreas gave a good example of typical error, when you writing a
concurrent code: trying to initialize the state after doing fork,
making assumption that we not working under ideal environment and
bound solution to specific implementation (knowledge on how scheduler
works e.t.c.).

Also, if changes, what Andreas proposed will take place, then fork
will be not a fork anymore (in original context), since it's semantics
puts much favor on execution of original process.

Also, in case when you will need/want to port your code on another
smalltalk dialect, your code have a good chances to not work
correctly. And if you may know, catching such errors can take a lot of
time.

-- 
Best regards,
Igor Stasenko AKA sig.