NFC read and write buffers not clearing - not sure if intended behaviour

I was doing a few tests with NFC tags and embedded receivers and thought to create a small phone app to help with my tests. I discovered a few quirks, which I thought to share.

Firstly when reading a tag using my app the NFC read message buffer does not clear.
http://ai2.appinventor.mit.edu/reference/components/sensors.html#NearField.TagRead
I found that I had to manually use the set.Message to clear this buffer.

This could well be intended behaviour as with some NFC tag ICs data is typically stored in EEPROM rather than SRAM, unless otherwise specified. I would curious to know if so otherwise it is a bug.

Then thanks some embedded code I was using I was able to capture some behaviour that indicates another quirk related to the NFC text to write method.
http://ai2.appinventor.mit.edu/reference/components/sensors.html#NearField.TextToWrite

Here I discovered that following a message write event, I could not find a way to clear the TextToWrite buffer as in it does not clear automatically and so it will always attempt to write to a tag. There is no method within app inventor to stop a NFC text write.

I even tried to manually clear this buffer using an empty text string but it still sends a blank message, so my embedded NFC receiver still got a NDEF header with zero text. I could not find a way around this issue, so I would consider this a bug.

ADDED NOTE: In my opinion using a single readMode true or false to control whether NFC read or write method is not workable as there are plenty use cases where you need both NFC Read and Write to be disabled. This is not possible if the NFC block is added to your app. As such two variables are needed for either.

On a side topic it is worth mentioning that the NFC text write method is actually missing two parameters, namely the language code and whether it is UTF-8 or UTF-16.

Similarly the read assumes text read is english and you are unable to interrogate the attached language code, which you would find in the NDEF header.