To make my point about what I am about to propose, first look at each construct to see if its obvious enough what each would mean:

for { ... }

for(test) { ... }

for(init; test; next) { ... }

for(var : a, b) { ... }

for(var : a, b, i) { ... }

for(var : arr) { ... }

for(num) { ... }
What I am proposing is to just use "for" for every kind of loop ("loop" didn't look as good, and "repeat" feels like the weird cousin of "while"). The idea is that there are fewer keywords, and the context would be easy enough anyway. The answers are (smashed together here so that people can guess first):
while(true) { ... }
while(test) { ... }
init; while(test) { ... next; }
for(var = a; var < b; var++) { ... }
for(var = a; var < b; var += i) { ... }
for(ix = 0; ix < size; ix++) { var = arr[ix]; ... }
for(blah = number; blah > 0; blah--) { ... } // uses DJNZ
Of course, I could throw out the last one if that's going a bit far (and I'd probably implement some of these only once everything else is in place), but I wanted to include several examples to make my point

...Opinions on this? (i.e. instead of having while/until/etc.)

You are probably right. One reason I liked it (other than that Go uses it) is that the infinite loop is just "loop { ... }", but without another keyword. Otherwise "while(true) { ... }" is easily detectable. "Arr" is some array variable. In other languages this sometimes looks like "foreach(var in arr)" (I used shortened names so as to not totally give away stuff; but perhaps people have seen that mechanism, or perhaps the code itself would make it clear enough). I do think that perhaps a version of the "for" that mirrors TI-BASIC could coexist and make some code easier to write (e.g. "for(x,1,10)" versus "for(x=1;x<=10;x++)"). To keep things simple, the for is also used for "foreach" loops in some languages; and with that, I figured that allowing it to have just a condition (or perhaps have nothing to signify a "forever" loop) would not be much of a stretch ... but I admit that things like "while" and "do while" read much better.

I can stick with the standard setup, but perhaps keep extra options for "for":

while(c) { ... } // loop while c is true
until(c) { ... } // loop until c is true
do { ... } while(c); // do ... and then repeat while c is true
do { ... } until(c); // do ... and then repeat until c is true
do { ... } // do "forever" (useful)
for(init; test; update) { ... } // C++/Java/C# "for"
for(var, start, end, inc) { ... } // BASIC "for" (optional "inc")
for(var : array) { ... } // "foreach" (probably added in later); possibly also
// work with funcs/cofuncs where the last of the return-values is a bool
One thing I would like to provide is a way to start a loop in the middle somewhere to avoid having to use duplicate code before the loop and within the loop (trust me, everybody runs into this sooner or later):

// "A" (a large chunk of code) is duplicated to do this:
A;
while(C) {
   B;
   A;
}

// My solution (just as it reads, i.e. begin at label "start"):
do(start) {
   B;
start:
   A;
} while(C); // ...but repeat the WHOLE loop "while C" is true

// A common solution (but requiring "loop manipulation"):
do { A; if(!C){break;} B; } // !C is evil

I agree with DJ on this one. Using "for" as the keyword for every kind of loop would get too confusing, especially for people who use whiles or do...whiles a lot. Personally I favor for loops, but the other two do have their uses. You could certainly keep the other options for "for," though. I just think the purpose of certain code would be easier to figure out if the typical words are used.

About starting at a specific space in a loop? I think it's a good idea. If you want to skip the first few lines of code from a loop for the first pass or some other pass it'd be nice. Are labels/goto's allowed outside of loops?

I definitely think there should be some designated way to show that the loop is starting at a label, so "do(start) {...}" or "do @start {...}" is fine with me (though I'd prefer the first way).

MORE Recent Updates:

After some long discussion (with elfprince13 and merthsoft over on Cemetech), I have decided to make 2 major changes (and to clarify/discuss a third point):

Function Syntax - Function (and function-pointer) declarations have now been changed so that the return value(s) are AFTER the argument-parenthesis, and multiple return values must be grouped by another set of parenthesis. It was decided that this is clearer for single-valued returns, and that multiple returns match the new "tuple" convention anyway (see the next section):

func(byte a, b):byte // Takes two bytes (a and b) and returns a byte
func(byte a, b):(byte,byte) // ...Returns TWO bytes
func():char // Takes nothing, returns a char
It was also agreed that more complex functions are easier to read this way. For example, compare the old and new syntaxes for declaring a function which takes an A and a [function which takes a B and returns a C] and returns a [function which takes nothing and returns a (function which takes and returns nothing)]:

func(A, func(B : C) : func( : func())) // Old "inner" setup
func(A, func(B) : C) : func() : func() // New "outer" setup

// A simpler example (can you tell what it does by looking?):

func( : func( : func(A : B))) // Old "inner" setup
func() : func() : func(A) : B // New "outer" setup
Tuples (in place of parallel assignment) - ASSIGNMENT IS NO LONGER IN PARALLEL! However, you can still operate on multiple values at once by grouping them together with parenthesis (as a "tuple"). A "tuple" in OPIA will be an abstract representation solely for the purpose of grouping values together (i.e. no tuple-variables: A function would return a "tuple" of values rather than one value which is "a tuple"). Any list of comma-separated values is a "tuple", and a tuple is just a list of values.
 - Assignment (and all else) has precedence over a comma; but parenthesis may be used to group things as normal.
 - A Tuple does not "bind" into a separate entity (i.e. stays "unpacked"). A "tuple within a tuple" is just one larger tuple. The benefit of this rule is simplicity: no "lists of lists" or "packing" to deal with (this also means that if you embed a call to [a function which returns two values] inside of another function call, then it fills two places of the argument list). The main motivation for this is so that (((X))) resolves to X as expected (rather than a tuple-tuple-tuple of X).

byte a, b = c, d;     // same as: byte a, (b = c), d;
byte (a, b) = (c, d); // same as: byte a = c, b = d;
byte a = (((b)));     // same as: byte a = b; (as expected)
(a,b,c) = ((x,y),z);  // same as: (a,b,c) = (x,y,z)
(a,b) = ((x,y),z);    // INCORRECT: (x,y) is still TWO items
It has been suggested that I allow "tuples of tuples" so that that "incorrect" example would be valid, by requiring "1-tuples" to be indicated by a comma: "(x,)" is a 1-tuple, while "(x)" is just x in parenthesis ... However, I still fail to see how this would be useful in a static and compiled language (versus it's usefulness in a dynamic and interpreted language like Python).

Interpreted Aspects (aka "This $ business") - The compiler will precompute whatever it can (e.g. so that you can use actual code to embed a computed value), but the $ operator REQUIRES the compiler be able to do this on something (and grants more liberties to do so, such as loop-unrolling). Here is an example:

byte a = 5, b = a+7;

if(a+b < 15) { doA(); }
else { doB(); }

while(a < 100) { a += a; }
$while(b < 100) { b += b; }

return $(a+b);

// The compiler precomputes that code, resulting in THIS code:

byte a = 5; // b = 12, but is never DIRECTLY needed, so it is removed

doB(); // 5+12 is clearly not less than 15

while(a < 100) { a += a; } // The compiler leaves loop alone,
// ... unless TOLD ($) to: b=12+12 ...24+24 ...96+96 ... b is 192

return $(a+192); // ERROR! (value of a is unknown; cannot evaluate)
More specifically, "$x" would mean "give me the actual value of x (assuming that you know it)", regardless of how "x" was declared; but declaring "byte $x" has the same effect as putting the $ on each and every occurrence of that "x". The same goes for functions as well (e.g. inline it and require the result to resolve to a determinable value). One of the major points to debate for this case is whether "interpreting" a function can result in some runtime code being left in, even if it the resulting value can be determined at compile time. I'm leaning on having it be strict, since a simple function ought to be automatically inlined anyway, so I don't mind letting people just assume that a 1 or 2 statement function would be inlined (unless the compiler decides that it's better not to anyway).

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

Very detailed, as always!