*snip*
>But here are some of the things that I still wonder about:
>-- will variables still really be "variants" -- that is, if I say "LOCAL lnSomething as Numeric" can I still say "lnSomething = [Vin]" later on without error?

Yes, you can. No error will be thrown.

>-- will we be able to specify types for parameters?

Yes. This will give us Intellisense when using the parameters while programming.

>-- if so, will we be able to be as general or as specific as we can be ("objBusClass as Object" or "objBusClass as MyBusClass") with a resulting speed gain as we get more specific?

I don't know what speed gain you are refering to. For development, the speed gain will be in not having to type all that stuff. However, there may a slight (and I do mean slight, if any) hit during development because the IDE has to read the class library and its hierarchy in order to display the appropriate information in the Intellisense dropdown.

If you are referring to an early binding speed gain, then no. VFP is still a late binding client.

>-- will VFP7 take advantage of type libraries to provider any sort of strong-typing when using CREATEOBJECT or CREATEOBJECTEX?
>

The type library will be used for Intellisense purposes and you will get a hint of what it should be. However, you still can assign a character value to a boolean and not generate a compiler error. The resulting run-time error will be the only indication that something went wrong.

>
>Put another way, is these really just attempts to make VFP look more like VB, and perhaps silence some critics? Or will they have real and tangible effects on our development? (By real and tangible, I do not mean "I get to see all the members of a list box" -- I mean speed and type-checking).

This is to enable VFP to work better with MSMQ/Queued Components. It's also supposed to boost productivity.