It looks like algorithms used by snmpwalk to decide if the string should be quoted depend on presence of MIB and presence of hint for an OID in the MIB, at least that's my understanding after taking a quick look at SNMP code. As a result, it is possible to get unquoted string that starts with a double quote character. When parsing such string, Zabbix assumes that it is a quoted string and expects it to end with an unescaped double quote character. As a result, parsing fails and returns "no data was found" or "invalid text following value" error.

Some synthetic data examples include:

.1.3.6.1.2.1.1.1.0 = STRING: "
.1.3.6.1.2.1.1.1.0 = STRING: "foo bar"
baz
.1.3.6.1.2.1.1.1.0 = STRING: "foo bar" baz
foo bar
.1.3.6.1.2.1.1.1.0 = STRING: "foo bar" baz

When testing with snmpsimd and snmpwalk, it is possible to get all these outputs.

This was discovered while reviewing real snmpwalk output after fixing ZBX-23200 where few .1.3.6.1.2.1.31.1.1.1.18.* OIDS contained seemingly quoted values and one of those values had additional data, something like this:

.1.3.6.1.2.1.31.1.1.1.18.1234561 = STRING: "xxx::xxx-xxx-xxx xx01"
.1.3.6.1.2.1.31.1.1.1.18.1234562 = STRING: "xxx::xxx-xxx-xxx xx02"
.1.3.6.1.2.1.31.1.1.1.18.1234563 = STRING: "xxx::xxx-xxx-xxx xx03" (shut:<something>)