Unexpected tag behaviour on choices with square brackets

[M-SomewhatUnlikely]

I'm using the version from the Unity asset store: called 0.7, it appears to be current (for the store).

I'm not getting the behaviour I'd expect from tags when they appear on choices that include square brackets. For example:

-> start
=== start ===
Run this in a player that can show you the tag output. # tag_1
Note which tags appear on which lines. # tag_2
* In this option... # tag_3a
	...Tags appear where the lines (including choice) appear, as I expected # tag_4a
	-> END
* But if you use square brackets[...] in the choice... # tag_3b
	Both tags (3b and 4b) appear on this line. # tag_4b
	-> END

Note that Inky treats tags as part of the string, and the Ink player in the Unity package takes them out properly but doesn't show them. I attach a Unity package with a version of BasicInkExample that appends tags to the output strings (you'll need to import the Unity integration separately). (I typo'd some tag names in the ink that's in the package, but you'll get the point.)

In responses to an issue on the core Ink repository, @joethephish says that tags aren't currently supported on choices. That's fine: I'm reading them when the choice text comes back as content.

He also says:

The main complexity I've seen is the question of how it should interact with the choice structure:
* A [B] C # tag
...since currently we only have tags on the end of a line. So currently that would mean that he tag is added to the content AC. But I guess we could simply also add the tag to the choice AB, which seems like the most straightforward unsurprising approach. Could potentially be awkward if you really don't want the tag on AC though.

But the tag isn't added to the content AC: it arrives with the subsequent line. The tag is read and stripped properly, but something about the square bracket case means that the tag doesn't make it into the state at the point that Joe describes.

Looking at the JSON, tag_4b appears to be stored where I'd expect, so this feels like an issue with the Unity integration's runtime, but I haven't had any luck working out how tags get into the state. (It's hard to confirm completely that it's not a core Ink problem, because I haven't managed to find/make a player that respects tags without using the Unity integration.)

I'm probably going to work around this by putting my tag information into a notation that I can read and strip when the text arrives (i.e. the pre-tags approach), but the project is already complicated and I had hoped to avoid custom notation (and the demands it makes on the writer) now that tags feel like they should be enough.