The real issue is, where to put it? "Some place" isn't too descriptive. Perhaps at the end of the current section?

That being said, it seems like an interesting way to do jump tables:

  ld hl, .table - 2
.loop
  inc hl
  inc hl
  cp [hl]
  inc hl
  jr nc, .loop
  ld a, [hli]
  ld h, [hl]
  ld l, a
  jp hl

.table
  dbw 50, [
    ld hl, [db "Try harder!", 0]
    jp ShowMessage
  ]
  dbw 120, [
    ld hl, [db "Good work.", 0]
    call ShowMessage
    ld hl, SND_CHIME
    jp PlaySound
  ]
  dbw 255, [
    ld hl, [db "Excellent work!", 0]
    call ShowMessage
    ld hl, SND_FANFARE
    jp PlaySound
  ]

It can be an explicitly marked constant pool, similar to ARM assemblers.

The one I saw defaulted to the end of the assembly after your code, but there was a command to relocate it to wherever else you wanted

Note that square brackets collide with memory accesses. In fact, this would mean that parsing is no longer context-free:

    ld hl, [niladic_macro_or_a_label_who_knows]

I'd suggest using curly braces instead.

    dbw 120, {
      ld hl, {db "Good work.", 0}
      call ShowMessage
      ld hl, SND_CHIME
      jp PlaySound
    }

Note that this kind of delimiters is used in quite a big family of languages already ;)

Unresolved question: how would label scoping work here?

Unresolved question: how would label scoping work here?

I assume locals before a global would be local to the braces and globals would work as always.

I saw this feature in the rare MIDAS assembler for PDP-10, which you'd think would be hard to get working or find docs for, but actually an easy self installing emulation package and extensive documentation for Midas and its OS are here ITS on Github

Quick comment: parens, brackets and braces cannot work for this. Parens are used for expressions, brackets by memory accesses, and braces by symbol expansions (including outside of strings). So something else would be needed.

Other than that, I'm not really sure about how useful this is; my main concern with this is code mixed in the middle of data, which I'm afraid would hurt readability in cases more trivial than in the OP.

Implementation doesn't sound too complicated, but I'm seeing major pain points, such as specifying the location at which the code should be stored, or the fact that looks a lot like LOAD, which is already very fragile. From my point of view, this doesn't add anything significant (prove me wrong though) so I'm not sure if it's worth the additional complexity.

After further discussion, I think this might be worth it though in fairly minor ways (compared to current solutions), so I won't close this, but this is low priority as far as I'm concerned. Anyone else willing to take a stab at it is welcome, however.

It can be an explicitly marked constant pool, similar to ARM assemblers.

The proposition here is quite different from ARM assemblers. The literal pools there are typically used when numeric immediates are used that cannot be represented in 8-bits, (combined with some number of rotates as per the spec). It is also used for syntax like LDR R0, =label where label is an address label, not a storage directive as the OP desires. A literal pool would then be set up which contains the address of label.

tl;dr I don't think this is a good idea, not least for the combining code/data argument. Also, I can't imagine a use case where such a syntax would be appropriate.

Quick comment: parens, brackets and braces cannot work for this. Parens are used for expressions, brackets by memory accesses, and braces by symbol expansions (including outside of strings). So something else would be needed.

In this case, double brackets would work perfectly. This might be complicated to parse, though, since the lexer would have to know to parse [[ as a single token instead of reading it as two [ symbols. But this is a long-term feature anyway...

If #244 were implemented, allowing two sections to be in the same bank even if they're floating, this could make use of it. The parser could allow reloc_16bit or reloc_16bit_no_str to be inline_code, which would parse as '[[' lines ']]'. The [[ would push a new anonymous section in the same bank as the current one (also backing up the current nListCountEmpty and nPCOffset values); the ]] would pop the section, restore nListCountEmpty and nPCOffset, and evaluate the whole inline code block to that section's address (with some new rpn_AddrSection function like rpn_BankSection).

The problem of implementing #244 is that there's no way to adapt the bin packing algorithm to work with the additional constraints.