Q:

Is that a Perl 6 Hash or Block?

This is a bit of unexpected behavior that's likely to bite beginners. First, is this intended? Second, what other things does Perl 6 use to guess which object to create? Does it start off thinking it's Block or Hash and change later, or does it decide on the end?
You can construct a Hash with braces and the fat arrow:
my $color-name-to-rgb = {
    'red' => 'FF0000',
    };

put $color-name-to-rgb.^name;  # Hash

Using the other Pair notation creates a Hash too. 
my $color-name-to-rgb = {
    :red('FF0000'),
    };

But, absent the fat arrow, I get a Block instead:
my $color-name-to-rgb = {
    'red', 'FF0000',
    };

put $color-name-to-rgb.^name;  # Block

The Hash docs only mention that using $_ inside the braces creates a Block.
There are other ways to define a hash, but I'm asking about this particular bit of syntax and not looking for the workarounds I already know about. 
$ perl6 -v
This is Rakudo version 2017.04.3 built on MoarVM version 2017.04-53-g66c6dda
implementing Perl 6.c.

A:

This only applies in term position1
Only braced code ({...}) that is in term position is subject to this DWIM.2
In these examples the {...} is not in term position:
if True { ... }   # always a block
class foo { ... } # always a package
put bar{ ... }    # always a hash index

For the rest of this answer {...} only means braced code in term position.
The summary
{...} is always a Block if it has an explicit or implicit signature, or includes top level statements, including variable declarations.
Otherwise, these are the only braced block forms that are a Hash:

{}
{...} where the ... is a list whose first element is a literal pair (eg :bar) or % sigil'd variable (eg %foo).

To force Block or Hash interpretation

To force {...} to construct a Block instead of a Hash, write a ; at the start i.e. { ; ... }.
To write an empty Block, write {;}.
To force {...} to construct a Hash instead of a Block, write %(...) instead, or follow the rules explained below.
To write an empty Hash, write {}.

An explicit signature means it's a Block
Some braced code has an explicit signature, i.e. it has explicit parameters such as $foo below. It always constructs a Block no matter what's inside the braces:
say WHAT         { key => $foo, 'a', 'b' } # (Hash)
say WHAT -> $foo { key => $foo, 'a', 'b' } # (Block)

An implicit signature also means it's a Block
Some braced code has an implicit signature:

Explicit use of a "pronoun" inside {...} means it's a Block with a signature, an implicit signature if it doesn't already have an explicit one. The pronouns are $_, @_, and %_.
Implicit use of $_ inside {...} via a method call without an explicit invocant means it's a Block with an implicit signature if it doesn't already have an explicit one. In other words, even { .foo } has a signature ((;; $_? is raw)) due to the .foo.
Use of an explicit "placeholder" variable (e.g. $^foo) inside {...} also means it's a Block with an implicit signature (with a $foo parameter in it).

As with an explicit signature, if braced code has an implicit signature then it always constructs a Block no matter what's inside the braces:
say WHAT { key => $_ }                     # (Block)
say WHAT { key => 'value', .foo, .bar }    # (Block)

Multiple top level statements mean it's a Block
say WHAT { :foo; (do 'a'), (do 'b') }     # (Block)
say WHAT { :foo, (do 'a'), (do 'b') }     # (Hash)

The second line contains multiple statements but they're producing values within individual elements of a list that's the single top level expression.
A top level declaration of an identifier mean it's a Block
A declaration is a statement, but I've included this section just in case someone doesn't realize that.
say WHAT { :foo, $baz, {my $bar} }        # (Hash)
say WHAT { :foo, $baz, (my $bar) }        # (Block)

The first line contains a Block as a key that contains a declaration (my $bar). But that declaration belongs to the inner {my $bar} Block, not the outer {...}. So the inner Block is just a value as far as the outer {...} is concerned, and thus that outer braced code is still interpreted as a Hash.
In contrast the second line declares a variable directly within the outer {...}. So it's a Block.
Still Blocks, not Hashs
Recall that, to be a Hash, the content of braced code must be a list that begins with either a % sigil'd variable or a literal pair. So these all produce Blocks:
my $bar = key => 'value';
say WHAT { $bar, %baz }                   # (Block)
say WHAT { |%baz      }                   # (Block)
say WHAT { %@quux     }                   # (Block)
say WHAT { 'a', 'b', key => $foo }        # (Block)
say WHAT { Pair.new: 'key', $foo }        # (Block)

When it's a Hash
Braced code that doesn't fall into any of the foregoing situations that force it to be a Block, and which is just a list of zero or more values that start with either a % sigil'd variable or a literal pair, constructs a Hash:
say WHAT {                  }             # (Hash)
say WHAT { %foo             }             # (Hash)
say WHAT { %foo, ...        }             # (Hash)
say WHAT { foo => 42, ...   }             # (Hash)
say WHAT { :foo, ...        }             # (Hash)
say WHAT { key => $foo, ... }             # (Hash)

Footnotes
1 See comments below answer about term position.
2 DWIM design is fraught. Good DWIM design is worth it. But every DWIM comes with corresponding WATs3. The key to good DWIM design is ensuring that, in general, WATs' barks are worse than their bites4; that the barks are useful5; and that the DWIM is considered worth the barking and biting.6
3 WAT refers to a dev's incredulous surprise when something seems crazy to them. It's known that for every DWIM that works for most folk, most of the time, there are inevitably one or more related WATs that surprise some folk, some of the time, including some of the same folk who at other times benefit from the DWIM.
4 The bite of the WATs related to this DWIM varies. It's typically a bark (error message) that makes the problem obvious, but can be much more obscure:
say { a => 42 }() ;  # No such method 'CALL-ME' for invocant of type 'Hash'   WAT? Oh.
say { a => $_ }<a> ; # Type Block does not support associative indexing.      WAT? Oh.

say { a => $_, b => 42, c => 99 } .elems  # 1                                 WAT?????

5 A "bark" is an error message or warning in documentation. These can often be improved. cf Lock.protect({}) fails, but with surprising message.
6 Community member opinions differ on whether DWIM design in general, or any given DWIM in particular, is worth it. cf my perspective vs Sam's answer to this question.

A:

The preferred Perl6 way is to use %( ) to create hashes.
my $color-name-to-rgb = %(
    'red', 'FF0000',
    );

I would not recommend people use braces to create hashes, ever. If they want to make a hash then %( ) is the proper way to do it.
If you are coming from the Perl 5 world it's best to just get in the habit of using %( ) instead of { } when creating a Hash.

