Verilog Simulation Code Blocks.

NB--There is a mismatch between these answers and the tutorial. I labeled 
both out[1:0] wires as A and B, then wrote up the solutions below. 
That wasn't what the tutorial said (it didn't mention B). So, your 
results are probably different, but most of this applies anyway.

(A.)
One can drop as many verilog boxes as one cares to into a single 
cell. The code in all the boxes will simply be concatenated 
together and inserted into the verilog module definition for 
the cell when the verilog "deck" is written. Provided the code 
in each verilog box has no errors nor conflicts with code in 
other the cell's boxes, compilation and running will work just fine.

(B.)
It depends on whether or not you added the B wire: if you didn't, 
compilation is ok, but running causes an error; if you added a B 
wire for out[1] in the same manner as A, compiling with iverilog 
will cause binding errors for"out". If you look at generated verilog 
code, test_myCell.v, you will see that "out[1:0]" has disappeared! 
Electric simplified for us, now only A and B are wires. If you fix 
this by changing your test code to refer to A and B, the compilation 
works. Note that it will not complain about the lack of arguments 
corresponding to the two output formatting specifications "%0d" 
and "%b" in the "$display()" call. But, at vvp runtime there will 
be error messages complaining "Missing arguments" every time it is 
called.

(C.)
The name "out" refers to some object named "out" in the verilog 
module definition code generated from the top-level cell, 
test_MyFirstCell. In that cell, there is a bus named "out[1:0]". 
One would think that that would generate "wire [1:0] out;" in the 
module "test_MyFirstCell" in test_MyFirstCel.v. But, Electric was 
too clever for us. Looking at test_MyFirstCel.v, we see that there 
are only two wires declared, "A" and "B", and no busses in 
module "test_myFirstCell". What happened was that in generating 
verilog code for module test_myFirstCell, Electric noticed that 
A was connected to out[0] which was connected to the port argument 
"out" of the instance "foo" of module "myFirstCell". So, Electric 
simply skipped the intermediate bus at the top level, and connected 
foo's port directly to wires A and B:

    noname__myFirstCell foo(.out({B, A}));

with B going to the port's high-order bit "out[1]" and A going to the 
port's low-order bit "out[0]".

(D.)
Adding that code to module "myFirstCell" would cause a compile-time 
error complaining "unable to bind A" and "A not defined in this scope", 
for instance. This is because the definitions for A and B are within 
the scope of the "test_myFirstCell" module, not the "myFirstCell" module.

(E.)
In test_myFirstCell, the effect of that code would be to print the 
values of wires A and B whenever they were changed by some event. 
Depending on where the code is placed (for instance, either before 
or after the "#1" delay), different values might be printed. Since 
foo.out is driven at time 0, the $display() call might produce "x" 
as a value for A and "x" as a value for B, if the call came before the 
#1 delay. Otherwise, the call should print "A = 0" and "B = 1", as 
these are the values driven for the output port of instance foo, 
"foo.out = 2'b10". Note that B is connected to the higher-order bit.