Being able to store data types other then a string in a data field for GUI's would be a very nice change in the engine. Right now when using objects in it, it can become rather tricky to work-around string limitation.

+1

I would like to see the eventHandler solution added in. It can be rather annoying when people come into a server at mission start or mid-way and start spamming the map with racial markers and other stupid crap.

Instead of creating a new ticket for this it appears that with the ARMA 3 1.18 Build and current Dev-build (5/20/2014) the issue has spread to all weapon based entities.
You cannot remove any weapon type from any container with removeItem, removeItemFromXYZ. This was working before Stable build 1.18 (1.14 if I recall).

Removing items them selves works just fine such as Scopes, Suppressors, glasses, hats, etc but not weapons.

The thing is, unassignItem is meant for unlinking it from it's designated slot / container. You can simply use the in-game inventory GUI to move the binoculars from the bino slot / container and into your inventory and you can't remove it with removeWeapon or removeItem. That's the issue that is present. Once a binocular based item is in a inventory container it can't be removed via script, the only work-around way is to assign the item then use removeWeapon but we shouldn't have to create work-arounds for a scripting command that should already remove it.

Items such as NV Goggles remove just fine from inventory containers with removeItem.

The issue to isolate it is related to the following commands running on the client.

clearItemCargoGlobal
ClearWeaponCargoGlobal
ClearMagazineCargoGlobal

By removing those three commands the mass desync has ended, there is still desync over time so further investigation should be looked into the engine, but to quickly see one of the issues those three commands cause desync issues when run on the client.

*EDIT* 5/17/2013

After more mission-side investigation removing the said commands above helped the early run of the mission (also clearItemCargoGlobal is broken, it's not global).

Over time with a mission using BIS_fnc_MP the BIS_fnc_MP_queue on the "bis_functions_mainscope" eventually builds up to an excessive 500+
I can see this isn't something BIS can do, maybe add a command to purge the queue that only the server can run or possibly add a limit of how far it can go.

Only real solution I guess for this is for the mission designer to purge such things.