By byte- and uint-prefixed strings, do you mean that number would be the length of the string?

Correct:
"banana" // .db "banana",0
r"banana" // .db "banana"
b"banana" // .db 6,"banana"
i"banana" // .db 6,0,"banana" ;z80 is "Little-Endian"

Ok, I've basically finalized all the (more than very trivial) language issues ... I am just going to repost:

Some final notes before I begin in (May or June?). THESE ARE DECIDED (tentatively):

The new numeric datatypes are byte, sbyte, int, and uint.

String literals can take on different forms:
::: "null terminated string"
::: b"byte-prefixed string"
::: i"int-prefixed string"
::: r"raw string"

Numeric literals are of type "int" by default. Type-casts can be used to be explicit: (byte)5;
Hexadecimal and Binary literals are prefixes with 0x and 0b, respectively, and default to type "byte" or "uint" types according to the number of digits used (so as to reflect a literal bit representation).

Dereferencing is now on the right-side:
::: *[]byte pa;    (*pa)[idx];
::: []*byte ap;    *(ap[idx]); // or just *ap[idx]

Constant (immutable) variables are defined with "const" in addition to the datatype.
Constant expressions (pasted in like macros) are defined with "const" alone.
It is illegal to mix "const" or "volatile" with the ":=" operator.

There are standard-, BASIC-, and iterator-style for-loops:
::: for(init; condition; update)
::: for(var: start, end, inc) (inc is optional)
::: for(var: array); for(var: someYieldyCofunc)

The inferred type of an array literal works as follows:
::: []T{...} = A static array of the given values
::: &[]T{...} = Pointer to the given static array
::: new [n]T = Pointer to a new (uninitialized) array allocation
::: new []T{...} = Pointer to a new array allocation (values copied from static array)

Arrays with the (first) dimension omitted ([]T or [,n]T) are pointers.
Arrays of the form [ , ,...] are rectangular (stored in one static allocation).
Arrays of the form [][][]... are jagged (the "inner" arrays are stored as pointers).
Arr[3..6] is a shorthand for the tuple expression (Arr[3], Arr[4], Arr[5]).
Tuples will remain "auto-unpacked", and no tuple-variables allowed.

Method receivers ("this") are ALWAYS (intrinsic) pointers.

Methods may be defined within structs, just as in Java/C# (compact/familiar).

There will be an "x@value" syntax for embedding variables within array literals.

Addressing goes on the LHS and applies to the whole RHS (e.g. &a[n] is &(a[n])).

Entities may not be defined within each other (e.g. no structs within structs, etc.).

Expressions cannot contain statements (declarations, assignments, calls, var++/var--).

Anonymous functions may may not refer to (non- static/const) external local variables.

All code is precomputed as much as possible (without unrolling loops or recursive calls).

The $ operator Requires something to be interpreted, including loops and recursive calls.

Bridge methods will be inserted for multiple "inheritance" of anonymous fields, as needed.

Control-flow constructs will indeed require parenthesis (avoids parsing conflicts with literals).

No "static" members of anything (but static local vars and static initialization blocks are allowed).

Entites Have Global Accessibility If They Are Capitalized, and namespace accessibility otherwise.

Look-Up-Tables (rather than Jump Tables) will be used with switches and if-else chains as possible.

Methods can only be defined for "identifier" types (structs, primitives, etc., but not funcs, arrays, etc.).

Namespaces may be nested ("Outer.Inner" syntax), and there will be a "using Namespace" mechanism.

Self-Modifying code will be used with cofuncs and switch-variables (Will consider an option to disable it).

Explicit variable addresses can be nominal (@"address") or refer to another variable (@x or @arr[n].foo).

No exception-handling or "try-catch" mechanism (use multiple return values or create an "Exit()" instead).

Type-casts will be represented traditionally (e.g. "(byte)(a+b)").

"Extra" Parenthesis are not allowed within datatypes ("func(...)" requires them, but []*T are *[]T are unambiguous).

Function pointers without any return values may point to functions with return values (e.g. func(byte) pointing to func(byte):byte).

Values will be passed/returned in registers such that any two functions with the same pattern of arguments will use the same registers for them.

Default arguments (and struct members) must come last, and will be embedded in functions so they can be pointed-to as their reduced versions.

An anonymous (nameless) struct/interface/cofunc/func within a namespace will take on the name of the namespace (e.g. "List myList" rather than "ListNameSpace.ListStruct myList"). This also gives namespace values ("List.staticValue") the feel of Java/C#'s static class members.

I plan on re-documenting the language once it is done or underway. I do want it to be a concise reference, but I will probably give better (more realistic) examples. The compiler will only be a command-line interface, so there will not be anything visual to show for. However, this will allow it to be integrated into whatever other program (like how different things link into Notepad++, etc.). I will probably make a visual editor; but this way the core language/compiler (and all of it's inner modules) stay modular / pluggable.

Are you using something like ANTLR, or are you making a custom parser?

He's only on the grammar right now, so no, the compiler is not currently working.

Yeah, that's what I'm doing with my compiler. I was using ANTLR, but I wasn't satisfied with its error reporting for the C# port, so I decided to write everything myself. I love the freedom of being able to customize everything. My lexer is done, and I'm working on the parser right now. My only problem is I don't have an exact syntax for it yet lol.

I took a quick look at your grammar before, and it looks good so far. I'll be able to take a better look at it later, though.

Sure! But yes, now wouldn't exactly be a good time for me either. My code isn't exactly the neatest as of right now. My language doesn't need a preprocessor, but the way I have everything set up, I'd like to think implementing one wouldn't be too hard. Plus my lexer isn't 100% done; it's more like 97%. I just need to add support for decimals / floats and hex.

Nice! That's similar to what I'm doing, except I only have statements and expressions. I have a method I created for extracting token patterns that I found is pretty useful, at least for namespaces. Yours is looking good, though!