World: r3wp

in case we wish to dynamically insert objects into the display and 
then remove them as they do in Javascript

yes, exactly. Dynamic structure.

Why?  If there's a tab order ... then there must be a serial structure

Which can be messed up all too easily by dynamic structure. Your 
program could reorder tabs for instance.

Or, as you say, a tab could be inserted/removed.

Eg.  I like to create tables first as instant feedback, and then 
fill them with data from an async function.

But I need to overlay a busy graphic which I can then remove ...

in the callback

Ok, so you as the programmer know that your table has a specific, 
static order at the time you need to fill it. No problem.

Did you also mean that you'd like ACTIONS associated with STRUCTURE 
elements anonymously?

view [
	; STRUCTURE
	text-list data files  ; <---- element #1
	code-area  ; <---------- element #2

	; ACTIONS
	[on-click [set-face ...] ] ; <---- actions for element #1
	[on-enter [ ... ] ] ; <---------- actions for element #2
]

well, I don't want to name each element of the structure

but maybe we have to .

We could combine both approaches. In the ACTIONS section, if there's 
a word followed by a block, then the word is the name reference to 
the element (eg. 'my-text-list), but if there is just a block, then 
the next element is taken anonymously.

Any objections to this vid enhancement?

not all structural elements will have an action

view [
	; STRUCTURE
	my-text-list: text-list data files ; <------ element #1
	code-area ; <--------- element #2

	; ACTIONS

 my-text-list [on-click [set-face ...] ] ; <----- actions for my-text-list

 [on-enter [ ... ] ] ; <------- actions for the next anonymous element 
 (in this case code-area).
]

I guess they will ... on-hover, on-tab etc

Yes, that could make some confusion. Specifying empty brackets [ 
] could act as a "ignore this element".

or, [] = don't override the default actions

view [
	; STRUCTURE
	my-text-list: text-list data files ; <-- element #1
	label "on-line"
	code-area

	; ACTIONS

 my-text-list [on-click [set-face ... ] ] ; <--- actions for my-text-list
	[ ]  ; <-- actions for label

 [on-enter [ ... ] ] ; <--- actions for the next anonymous element 
 (code-area)
]

so the layout parser sets the action properties of each gui element

Just thinking, should the actions section be specified in a block 
? eg:

view [
	; Structure
	my-text-list: text-list

	; ACTIONS
	actions [
		my-text-list [ ... ]
	]
]

Now, recursive structures.

Sub-panels.

the actions would have to be specified in the panel defintion

So each panel only specifies the actions of its own top level elements.

So:

view [
	; Structure
	label "hello"
	panel [
		; Structure
		my-text-list: text-list
		actions [
			my-text-list [ set-face ... ]
		]
	]
	actions [
		[ ] ; <--- actions for the LABEL
		[ ] ; <-- actions for the PANEL
	]
]

yes ...

actions: [ skip 1 [ someaction ] ]

Hmm. Using SKIP would be like using GOTO. The trouble it's trying 
to avoid is having lots of dummy empty brackets, of course - a noble 
goal.

It would be better to simply use a name-reference (keeping in mind 
that these are now, in Rebol 3,  local to the window context), for 
jumping across a (possibly varying, during code maintenance) number 
of empty action placeholders.

or, how about 

actions [ label [ ] panel [] ]

so we can assign by type

now we don't have to keep the actions in order unless there are more 
than one of the same type

view [
	; Structure
	label "hello"
	text-area
	my-text-list: text-list
	code-area

	actions [
		my-text-list [ set-face ... ] ; <--- action for my-text-list
		[ ] ; <-- action for code-area
	]
]

So, above, during code maintenance any number of extra fields can 
be inserted before my-text-list and it won't affect the actions assignment.

view [
	; Structure
	label "hello"
	text-area
	my-text-list: text-list
	code-area

	actions [
		text-list [ set-face ... ] ; <--- action for my-text-list
	]
]

there's only one text-list in the window

There can be an overlap in names, so we have to deal with this possible 
ambiguity:
view [
	text-list: text-list  ; <--- TEXT-LIST #1
	text-list  ; <--------- TEXT-LIST #2
]

Where the name-reference is the same as the element type (text-list).

we could just use order ... and not names

actions [
	text-list [
		[ text list 1 ]
		[ text-list 2 ]
	]
]

Perhaps lit-words could be used to indicate that it's a type, eg:

	actions [

  'text-list [ set-face ... ]  ; <-- Action for all text-lists in the 
  window.
	]

this would allow code reuse

(Ugh... the sight of hard-coded numbers make me a bit queasy...)

the numbers aren't there ...

just using the order  in the block

oh

so you meant:
	actions [
		text-list [
			[ ... ] ; <-- action for the first text-list
			[ ... ] ; <-- action for the second text-list
		]
	]