You wrote, that the addressing spaces cannot be forward referenced. Not the labels.

Yes, I did not state that correctly even though I had labels in mind.

if used space
     display 'Space used',13,10
end if

space::
db 'ABCD'
load a byte from space:$$    

if used tester
        display 'Tester used',13,10
end if

; this would cause error:
; dd tester

tester = 0

tester = 1

dd tester    

But "defined" has not yet been upgraded to work correctly with these new labels, please wait for another update.

if defined space
      display 'space defined 1',13,10
end if

space:: db 'ABCD'

if defined space
      display 'space defined 2',13,10
end if    

P.S. Or again, you could allow the addressing space labels to be forward referenced, as I mentioned before, because their semantics is nearer to the normal labels than to the redefined numerical variables.

Yes, it works as it should in this case.

The fact that they can only be forward-referenced comes from the internal gimmicks

But it is not a big deal, IMHO.

db 'ABCD'
virtual
      load a from space:data_end-1
    display a,13,10
end virtual
space:: data_end:    

I assume, you mean "can not be forward-referenced".

I just thought, it was an intentional design decision rather than a required measure.

I would probably be able to find a way around it and implement this one special case (forward-referencing label that marks the same space as the current one)

I think that the simple rule of no forward references makes things much more plain and simple, and we are not losing much.

virtual at 0
  __address_space1::
        db 1
end virtual

__address_space2::
       rb 1

store byte 1 at __address_space1:0

;db 1   ; this fixes the binary.    

macro @make_a_thing id
{
        virtual at 0
            id#::
                .stuff rd 1
        end virtual
}

macro @use_a_thing id
{
        local d

        store dword 'x' at id#:.stuff
        load d dword from id#:.stuff

        display d
}

@make_a_thing x
@use_a_thing x
@use_a_thing x    

Another interesting aspect to this is that the preprocessor can now create, reference and share dynamic structures in these virtual address spaces.

my_label:

        jmp .next ; <- cannot find my_label.next

; from macro
virtual at 0
        try::
        .that dd 0
        .this dd 0
;       .next dd 0 ; <- would fail due to redefinition
end virtual
;end macro

.next: ; <- renamed to try.next

dd .this ; previously non-existent    

The preprocessor has no access to these features, because LOAD/STORE directive operate at assembly time. But yes, you can now create dynamic structures (buffers, tables, etc.) and use them freely...

...wouldnt it be simply better to consolidate/extend the load/store things even on not yet assembled code, instead of creating such
new feature that, at least for now, seems to assert just now, completely
and openly again, the weakness of virtual ?...

virtual at ?
...
end virtual
    

hopcode, I really don't understand any of your posts here.