You're creating a hashtable, whose entries cannot be accessed with positional indices (0, 1, ...); instead what you specify inside [...] is an entry key.

Therefore, use the .Keys property for enumeration:

$test = @{set01 = '0'; set02 = '1'}
foreach (test.Keys) {
  $key 
  # To access the entry's *value*, use $test[test[$key]
}

The result is:

set02
set01

Note how the keys were enumerated in a different order than they were defined, because [hashtable] instances do not guarantee any particular enumeration order.

In PSv3+ you can use an ordered hashtable to remedy that, which would also allow you to use positional indexing - but note that positional indexing then returns the entry values, not the keys:

$test = [ordered] @{set01 = '0'; set02 = '1'}
for (i -lt $test.Count; $i++) {
  $test[$i]
}

Note: While you could use $test.Keys[$i] to access the keys, as in Dandre's answer, direct enumeration of the keys with foreach (test.Keys) is less verbose and faster; the only good reason to use index-based iteration with $test.Keys[$i] would be if index $i weren't just a helper variable, but were required for operation, such as for outputting a string that reflects both a key and its index.

The above therefore yields:

0
1

Note that the for syntax is not only verbose, it actually performs worse than foreach, and in case you do need explicit indices, use foreach with the indices generated via the range operator (..), which is not only faster but also arguably more readable than the for loop:

$test = [ordered] @{set01 = '0'; set02 = '1'}
foreach (test.Count-1)) {
   $test[$i]
}

While it is less memory-efficient, because the array of indices must be created as a whole up front, that is usually not a concern.

You have some options here.

Enumerating through keys:

foreach ($key in $var.Keys) {
    $value = $var[$key]
    # or
    $value = $var.$key 
}

Enumerating key-value pairs (which you've discovered, but may not be using effectively):

foreach ($kvp in $var.GetEnumerator()) {
    $key = $kvp.Key
    $val = $kvp.Value
}

Shorthand is not preferred for scripts; it is less readable. The %{} operator is considered shorthand. Here's how it should be done in a script for readability and reusability:

Variable Setup

CopyPS> $hash = @{
    a = 1
    b = 2
    c = 3
}
PS> $hash

Name                           Value
----                           -----
c                              3
b                              2
a                              1

Option 1: GetEnumerator()

Note: personal preference; syntax is easier to read

The GetEnumerator() method would be done as shown:

Copyforeach ($h in $hash.GetEnumerator()) {
    Write-Host "$($h.Name): $($h.Value)"
}

Output:

Copyc: 3
b: 2
a: 1

Option 2: Keys

The Keys method would be done as shown:

Copyforeach ($h in $hash.Keys) {
    Write-Host "${h}: $($hash.$h)"
}

Output:

Copyc: 3
b: 2
a: 1

Additional information

Be careful sorting your hashtable...

Sort-Object may change it to an array:

CopyPS> $hash.GetType()

IsPublic IsSerial Name                                     BaseType
-------- -------- ----                                     --------
True     True     Hashtable                                System.Object


PS> $hash = $hash.GetEnumerator() | Sort-Object Name
PS> $hash.GetType()

IsPublic IsSerial Name                                     BaseType
-------- -------- ----                                     --------
True     True     Object[]                                 System.Array

This and other PowerShell looping are available on my blog.

PowerShell allows you to define what is known as Alias Property for specified types or instances.

Name happens to be an Alias Property added to the DictionaryEntry instances:

$getMemberSplat = @{
    InputObject = [System.Collections.DictionaryEntry]::new('foo', 'bar')
    MemberType  = 'AliasProperty'
}

Get-Member @getMemberSplat

# Outputs:
#
#   TypeName: System.Collections.DictionaryEntry
#
# Name MemberType    Definition
# ---- ----------    ----------
# Name AliasProperty Name = Key

We can see that the property is an extended member of DictionaryEntry using Get-TypeData:

(Get-TypeData System.Collections.DictionaryEntry).Members['Name']

# ReferencedMemberName MemberType IsHidden Name
# -------------------- ---------- -------- ----
# Key                                False Name

Alias Properties can be added to a specified type using Update-TypeData, for example:

$updateTypeDataSplat = @{
    TypeName   = 'System.IO.DirectoryInfo'
    MemberType = 'AliasProperty'
    MemberName = 'AbsolutePath'
    Value      = 'FullName'
}

Update-TypeData @updateTypeDataSplat

# Now using the new Alias Property:
(Get-Item $pwd).AbsolutePath
# Should be the same as:
(Get-Item $pwd).FullName

They can also be added to instances of a type with Add-Member, for example:

$myObject = [pscustomobject]@{
    MyProperty = 'hi'
}

$addMemberSplat = @{
    InputObject = $myObject
    MemberType  = 'AliasProperty'
    Name        = 'MyAliasProperty'
    Value       = 'MyProperty'
}

Add-Member @addMemberSplat

$myObject.MyAliasProperty # hi

And, for custom types, can be defined through a Types.ps1xml file, the linked PowerShell doc has a mention on the built-in type system and the built-in defined aliases:

For example, by default, array objects (System.Array) have a Length property that lists the number of objects in the array. However, because the name Length does not clearly describe the property, PowerShell adds an alias property named Count that displays the same value.

Worth noting here that .Count should've never been an Alias Property in PowerShell 5.1 since .Count is an array's Explicit Interface implementation. In PowerShell 7+ we no longer see .Count as an Alias Property but as just Property:

# PowerShell 7.4
PS ..\pwsh> Get-Member -InputObject @() -Name Count

   TypeName: System.Object[]

Name  MemberType Definition
----  ---------- ----------
Count Property   int Count {get;}

# Windows PowerShell 5.1
PS ..\pwsh> powershell 'Get-Member -InputObject @() -Name Count'


   TypeName: System.Object[]      

Name  MemberType    Definition    
----  ----------    ----------    
Count AliasProperty Count = Length

Ideally, in my opinion, we should the definition as int ICollection.Count {get;}.

As for, why do you see Name and Value instead of Key and Value, this is defined by the built-in format files, in this case, the one that targets the DictionaryEntry type. You can see this by yourself:

Get-FormatData System.Collections.DictionaryEntry |
    Export-FormatData -Path DictionaryEntry.format.ps1xml

Get-Content DictionaryEntry.format.ps1xml

Fragment below is an extract of the format.ps1xml for DictionaryEntry. See about_Format.ps1xml for more details.

    <View>
      <Name>Dictionary</Name>
      <ViewSelectedBy>
        <TypeName>System.Collections.DictionaryEntry</TypeName>
      </ViewSelectedBy>
      <TableControl>
        <TableHeaders>
          <TableColumnHeader>
            <Width>30</Width>
          </TableColumnHeader>
          <TableColumnHeader />
        </TableHeaders>
        <TableRowEntries>
          <TableRowEntry>
            <TableColumnItems>
              <TableColumnItem>
                <PropertyName>Name</PropertyName>
              </TableColumnItem>
              <TableColumnItem>
                <PropertyName>Value</PropertyName>
              </TableColumnItem>
            </TableColumnItems>
          </TableRowEntry>
        </TableRowEntries>
      </TableControl>
    </View>

Note: This answer applies equally to situations where an API directly returns an enumerator object.

Using .GetEnumerator() returns an enumerator^[1] for the key-value pairs, which is not the same as the results of the enumeration.

• An enumerator must be iterated over via its .MoveNext() method in order to perform actual enumeration. However, you can let PowerShell do this for you, as shown below.

To get the desired behavior, force enumeration via @(...), the array sub-expression operator, and use the results:

# Note the use of @(...), which collects the enumerated objects
# in an [object[]] array.

# Get an array of key-value pairs.
$KeyPairs = @($ht.GetEnumerator())

# Get the first key-value pair.
@($ht.GetEnumerator())[0]

Note:

• In the pipeline it is PowerShell itself that performs the enumeration of an enumerator object, which is why something like
  $ht.GetEnumerator() | ForEach-Object { <# work with each key-value pair #> } does work.

• In the pipeline, hashtables / dictionaries, which are technically also collections, are not enumerated by default, unlike list-like collections such as arrays.^[2] That is, hashtables / dictionaries are sent as a whole through the pipeline by default, which is why a call to .GetEnumerator() is needed to return an enumerator for their entries (key-value pairs), which the pipeline then enumerates.

As for what you tried:

$KeyPairs
# Nothing is returned as if $KeyPairs lost its value

Because $KeyPairs contains an enumerator, it is done enumerating after the first enumeration that output to the pipeline (the display) implicitly performed, and therefore there's nothing left to enumerate on re-invocation - unless you call $KeyPairs.Reset() first.
However, note that not every enumerator is guaranteed to support .Reset() for repeating an enumeration - some enumerators invariably perform one-time-only enumerations.

($ht.GetEnumerator())[0] # !! DOESN'T WORK

• An enumerator cannot be indexed into.

• PowerShell treats it like a single object (which it is) and falls back to its own indexing, where it allows even single objects (scalars) to be indexed for the sake of unified handling of collections and scalars; in that case, [0] is an effective no-op, simply returning the single object itself (similar to how (42)[0] and (42)[-1] are the same as 42)

^{[1] Specifically, .GetEnumerator() returns an object that implements the System.Collections.IDictionaryEnumerator interface.}

^{[2] See the bottom section of this answer for which types PowerShell does and doesn't automatically enumerate in the pipeline.}