llListFindList question

I have always used a trick like this:

if (llListFindList(d_list + c_list, [msg]) != -1){

to search through multiple lists for llDialog returns. This little trick no longer works in MONO, instead it appends the c_list to the end of the d_list. I have filed a JIRA on it: https://jira.secondlife.com/browse/SVC-1515

But am not sure this is really a bug or if it was actually doing it wrong from the beginning. Can't find an entry in the wiki's stating you COULD do that.

list a_list = ["a", "b", "c", "d", "e", "f"];
list b_list = ["integers"];
list c_list = ["1", "2", "3", "4", "5", "6"];
list d_list;
key owner;
integer chan = -87643;

default {
	touch_start(integer n) {
		owner = llGetOwner();
		d_list  = [];
		d_list += b_list +  a_list;
		llListen(chan,"","","");
		llDialog(owner,"test",d_list, chan);
	}
	listen(integer channel, string name, key id, string msg) {
		if (llListFindList(d_list + c_list, [msg]) != -1){
			llOwnerSay("@llListFindList; " + (string) d_list);//???????????????
			if(msg == "integers"){
				llOwnerSay(msg);
				llDialog(owner, "integers", c_list, chan);
			}
			else
				llOwnerSay(msg);
		}
	}
}

LSL1 returns: Object: @llListFindList; integersabcdef
MONO returns: Object: @llListFindList; integersabcdef123456(d_list now contains more entries)

Comments?

I would say it is a bug, as you have no assignment set, it should concatenate the lists but discard the result after the function completes. I t will break a lot of things if it is not fixed.

Bug, for sure.

and a nasty one at that, I've used similar tricks in more than just list finds, precisely because I did not want them to be a single list (like when I want a shorter test list to search in some cases etc). making assignments and mangling my data is bad, bad mono, no cookie for you.

voted
at a guess they are storing the concatenation in the first named value to speed up calls or reduce memory usage, instead of creating a temporary value