This is probably the making of a bug report that I’ll post in the sweet by-and-by.
An existing (and long-standing) TO-DO task already covers this issue: Blender development todo list – Scripting (T55367), which is a roll-up of a number of incomplete and outstanding items needed for Python scripting. This particular issue falls under the Python/RNA API Design TODO rubric. The resolution of Task 32581 Mesh properties API does not allow for zeros in byte array is a partial fix that does not fully address the to-do; a mesh polygon boolean/float/integer/byte buffer layer that a python script writer might use to associate additional properties with mesh polygons is not wholly in place yet. There are more TODO’s then there are developers to do them, a perennial Blender problem.
The immediate trigger to the abort that I observed seems to be in
void rna_MeshStringProperty_s_set(), introduced in the commit to - at least partially - address T32581; it creates and populates a simple structure,
MStringProperty which ultimately is associated with a specific mesh polygon in the property layer. It has two parts: a fixed buffer (call it s) and a count of bytes (call it len). In the example above, ‘Ian Hubert’ are the data and ‘10’ is the count.
rna_MeshStringProperty_s_set() sets the fixed buffer part, but does not set the len part, defaulting it to zero. That has ramifications for client callers of this function, which are lead to believe that these
MStringProperty buffers, established by this function, have zero bytes of data, the genesis of the abort I described in the last post.
I gather that this deficiency is a known issue, awaiting the good, full, sweetness of time to fix. I also gather that - names like
MeshStringProperty notwithstanding - this portion of the Python API is being retooled to accommodate buffers of bytes, and byte buffers are not strings. They may have zero-valued bytes in their midst, which can confound naive uses of tools like
rna_MeshStringProperty_s_set() goes about setting buffer length will take some thought and design choices. Perhaps callers should just tell this function the length of their byte buffers. Perhaps not. These are API protocol decisions that haven’t been made yet.
You can read the date stamps on T32581 and the commit that addressed it - partially - as well as I can. Everyone - alas! - is dancing as fast as they can. So, if you have workarounds, they may just have to work around for some time to come. Take care.