Clarify how blocks are allowed/ignored.

I've done several tests on how blocks are allowed, but I'm not sure I understand the hierarchy of allowed blocks/tags.

Starting situation :

• the Winter.Blocks plugin
• a custom plugin defining a block blog_featured_image.block :

name: ...
description: ...
icon: icon-picture-o
tags: ["blog"]
fields:
    ...

According to the documentation :

allow: An array of block types that are allowed to be added to the widget. If specified, only those block types listed will be available to add to the current instance of the field. You can define either a straight array of individual blocks to allow, or define an object with tags and/or blocks to allow whole tags or individual blocks.

Example 1:

type: blocks
allow:
    - richtext
    - columns_two
    - title
    - blog_featured_image
ignore:

This give me 4 available blocks.

Example 2:

type: blocks
allow:
    blocks: 
        - richtext
        - columns_two
        - title
        - blog_featured_image
    tags: 
        - blog
ignore:

This give me only ONE block (blog_featured_image) because it's the only one that is both in allowed blocks and has its tag in the allowed ones.

Example 3:

type: blocks
allow:
    blocks: 
        - richtext
        - columns_two
        - title
    tags: 
        - blog
ignore:

It gives me NONE of the blocks because none of them has the tag blog in his definition!

Question:

or define an object with tags and/or blocks to allow whole tags or individual blocks.

I thought that in examples 2 and 3, my list of allowed blocks would include those defined in the allow/blocks and those whose tags are present in the allow/tags.
But from my own test I deduce that it's either one or the other, but not both.

@LukeTowers can you confirm that this is the expected behavior?

Start with the blocks documentation for the allow and ignore options, then compare the stated behavior with the three YAML examples in this issue. Determine whether block names and tags are combined or treated as alternatives, and update the documentation so the resulting available blocks and expected behavior are unambiguous.