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.

Ok, how is this setup for datatypes and literals?

byte, char, bool: unsigned 8-bit values
sbyte: signed 8-bit values
int: signed 16-bit values
uint: unsigned 16-bit values

Numeric Literals would be resolved (by default) as follows:
55: int
(55i: int)
55u: uint
55b: byte
55s: sbyte

Hexadecimal and Binary literals would depend on the number of digits for how it resolves (by default), but explicit indicators can be used as well:
0x1: byte (1 or 2 digits)
0x001: uint (3 or 4 digits)
0x001b: byte (b indicator)
0x1i: int (i indicator)

0b1: byte (8 or less digits)
0b000000001: uint (8+ digits)
0b1u uint (u indicator)

...Note that those are DEFAULT evaluations (e.g. "X := 5" makes X an int); but a clear context may result in a different type (e.g. perhaps the compiler can tell that looping from 1 to 10 only needs a byte).

For string literals:
"null terminated string"
r"raw string literal"
b"byte-prefixed string"
u"uint-prefixed string"

... How does that all sound?

I just want to note that I've been updating/revising that list in my previous post (as well as cleaning it up and making it MORE READABLE) ... Any opinions?

Well, you can put as many spaces and tabs where-ever you want
Sorry, TI-BASIC is one of very few languages I know of which is that "loose"; though I might consider whether or not I really need to require semicolons -- there were places where they were necessary, but I'll look at it again. I am going to have it give very nice error messages (specific, location, and give lots of error messages rather than just quit).

I have updated the Overview to reflect my changes for arrays, tuples, functions, and default arguments.

As for interpreted stuff ($), I think that I want it to always be "deep" (recursive). That is, "$foo(...)" will cause ALL of foo to be interpreted, and "$while(...) { ... }" would cause everything in the loop to be interpreted (including inner constructs). This means that all variables declared within must be determinable, but external variables referenced may be affected at runtime.

The reasons for choosing a "deep" evaluation (versus just that "layer") are that (1) it's easier to mark a section, and (2) this is the more likely use anyway. I'd rather let single layers be optimized by the compiler rather than see people put $'s all over the place where they think that an optimization can occur ... but I do like to allow "Hey, interpret that whole thing ... I just didn't want to compute the values and embed them all by hand".

One other thing: I think I want to replace "const" values with a "final" modifier, on the grounds that a "final" value is actually embedded in the program as an (immutable) variable (e.g. embed "BIG_UGLY_STRING" as a final value, rather than once for EACH time it is used) -- as in Java. As for value-holders, you can use $ to indicate this anyway. How does that sound?

Multi arrays with [] seems like a must. Instead of tuples, can't you just return an array?

Multidimensional arrays are awesome
...and you could return an array if you really liked...
byte (x,y) = foo(1,2);
func foo(byte a, b): (byte,byte) {
   return (m,n);
}

[2]byte xy = bar([2]byte{1,2});
func foo([2]byte ab): [2]byte {
  return [2]{m,n};
}

[1]byte z = boo([1]byte{1});
func boo([1]byte c) {
   return [1]byte{m};
}...but I think tuples are a worthwhile feature (and yes, they are loose enough to be equivalent to a list of function arguments).

By the way, even if you make the language similar to standard languages, when this comes out, you should really start writing a good tutorial for it. Preferably make one for people with no coding experience, so that for BASIC coders (the ones usually looking for alternatives) can easily pick up OPIA.

I try to design everything in the best fashion regardless of other languages; though when I use a feature that other languages have, I try to reflect forms that are common if I can; but sometimes I find "better" forms (the cofunc combines what other languages present as closures and generators/iterators). ... But I definitely plan on focusing on other details after the language and compiler are designed (documentation, tutorials, GUI tools, defining standard libraries. NOTE: These are the things that people can be VERY involved in later on!!)

I've been thinking of making a game based on this idea: It would involve robots moving around on a grid which would have "instructions" in various locations. The instructions would be collected into a program, which can then be dropped onto the grid as an instruction of it's own. There might be multiple robots that can influence eachother ... I haven't decided the objective though

Recent Updates (language/discussion):

Gotos - I determined that you can ALWAYS create structures in place of gotos, so long as the gotos are forward and don't jump "in" (at the very worst, you can use a "do...while(false)" as a container to break from) ... and then I determined that it was cleaner just to allow such gotos. The rules for gotos are that you can only jump foward, within the same function, and never INTO another construct (out of is ok). The "do(start) { .. }" is the only exception, which is provided specifically (see previous posts). You can still "break" and "continue" and even "break foo" or "continue foo"; constructs are labeled just by placing a label before them (though I prefer this to be on the previous line so as not to mess up the indentation and to match the format of other labels).

"Flattened" Hierarchy - I want to prevent programs/source from getting layered by keeping everything (aside from local and member variables) at the top level. This means two things: (1) No "nested" definitions: Entities such as structs, funcs, etc. cannot be defined inside of eachother (with the exception of methods and cofuncs being defined in structs). (2) Namespaces cannot be "nested" (they are declared at the top of the file, like a package declaration); and no more "using" keyword either (shorter namespace names are preferred).

Default values for function arguments - Although it is sort of contrary to parallel assignments, default values are given to function arguments as most people would expect (noting that only the last arguments in a function can have default values):

func Foo(byte a, b=2, char x='Y', y='Z') { ... }
Foo(1,2,'a','b'); // Normal usage
Foo(1,2,'a');   // Short for Foo(1,2,'a','Z');
Foo(1,2);     // Short for Foo(1,2,'Y','Z');
Foo(1);     // Short for Foo(1,2,'Y','Z');
Multiple Assignments - Basically, "each(a,b,c)=d;" replaces "a=b=c=d;". This can get complex with lists of values:

each(a,b,c) = x; // Instead of (a=b=c=x;)
each(a,b,c),d = x,y; // Instead of (a=b=c=x; d=y;) or (a,_ = b,_ = c,d = x,y;)NOTE: A more likely case than (...=x,y;) is a function which returns multiple values (...=twoValues();).

Method Declarations - Methods can be declared directly within structs as an alternative to begin declared with "structName." in front (both forms will be valid). I feel that this more compact syntax is easier to read in many cases. Nevertheless, you can use either form, and they mean the same thing:

struct Foo { func Bar(...) { ... } } // declared internally
func Foo.Bar(...) { ... } // declared externally
Choosing Explicit Variable Addresses - This is done by placing the "@address" after the variable name. Use a string literal to specify an assembly-coded address, or another variable to share memory (overlap) with. Variables can be declared inside of array literals, though I have not chosen a good syntax yet (that might sound bizarre but it's actually very useful):

word cursor@"curcol"; // cursor will refer to "currow" in the assembly code.
byte curCo1@cursor; // curCol now refers to the leading byte of cursor
byte curRow@cursor+1; // refers to the trailing byte of cursor. WE CAN DISCUSS THIS SYNTAX
func() f@"routine"; // f() now calls an assembly routine directly

// Embedding variables within an array:
values := [6]byte{0,1,2,3,4,5};
byte a@values[2]; // a is literally stored at value[2]
byte b@values[3]; // b is literally stored at value[3]
a = 1; // values[2] is now 1;
values[3] = 2; // b is now 2;

// More compact way of embedding variables in an array can be one of these:
values := [6]byte{0, 1, a=2, b=3, 4};
values := [6]byte{0, 1, a@2, b@3, 4};