I like it better

(1)
In an other message you said that one of those 3 objects needn't be closed. That is correct
In this case, you don't need to close loStream

Because closing a stream adapter automatically closes the underlying stream. But you have to remember that

Closing a stream more than once is not a problem

In this case
The using works from inside out ( deepest level first, then one level up)

(inner level) Closing loStreamReader closes loStream
(outer level) loStream which has been closed is closed again

So even when an exception is thrown in the StreamReader constructor, loStream will still be closed

I think it's cleaner code - with the nested using, you don't have to 'know' that the adapter closes the underlying stream

>                    Using loStream As System.IO.Stream = loHttpWebResponse.GetResponseStream()
>
>                        Using loStreamReader As System.IO.StreamReader = New System.IO.StreamReader(loStream)
>                            cHTML = loStreamReader.ReadToEnd()
>                            llSuccess = True
>                        End Using
>
>                    End Using

(2) You also said that you had seen some constructs where only one using was used
That is possible (but I think you need at least two usings) with a chain of stream decorators (Deflate/Crypto/GZip/Buffered).
Closing a decorator closes the stream used in the decorator constructor

(3) There are exceptions, eg MemoryStream doesn't need to be closed/disposed.

I am all for the nested usings

- It takes a lot of brain work, just to figure out which type you can take of the using chain.

- It's also cleaner code (and easier to read - was this an exception or not ?)

- It's more bullet proof

- You can never go wrong