Appears to be event related.
The wrong value is evaluated in 'History of events'.
In 'Event details' the wrong value is evaluated for 'Event' too but not for 'Trigger'
This bug is not minor as it prevents keeping a record of the value that caused the issue in the trigger list.
Another variation I see often:
In 'Status of triggers' it is evaluated to:
Expect more than 0 foo processes
In 'Last 20 issues' it is evaluated to:
Expect more than *UNKNOWN* foo processes
I believe I found the cause.
In 'Status of triggers' the API is used to query and expand the value/macro:
API::Trigger()->get('expandDescription' => true)
CTrigger::get()
CTriggerHelper::batchExpandDescription()
batchExpand()
expandDescriptions()
expandItemMacros() 
queries items table
replaceMacroValues()
In 'Last 20 issues' it's not the API that is used for that task:
make_latest_issues()
CEventHelper::expandDescription()
CEventDescription()
resolveItemValueMacro() queries history table
formatItemValue()
Due to the fact the the item in question has 'Keep history' set to 0, querying the history will probably result to NULL.
Would be nice if either the API is used in 'Last 20 issues' too or querying data is done in the same way the API does.
as 2.2 does away with history value being kept in the item table, history of one day would be required for this to work, and i assume this issue will not be relevant anymore
Agree.
But still a bug for 2.0... and who knows when a stable 2.2 will be released (that is ready for production) 
This is not exactly a bug, it's by design. It's important to notice that in the "Status of triggers" page we display triggers, but in "Last 20 issues" and some other places - events. And the {ITEM.VALUE} macro is resolved differently for triggers and events. For triggers it always displays the latest value of an item and acts the same way as the {ITEM.LASTVALUE} macro. For events, it displays the latest value of an item before the event happened.
This is somewhat confusing and may be redesigned in the future.
zalex_ua yeah, it's suggested to be redesigned in ZBX-6491
zalex_ua as for 2016-04-05 it has been indeed changed in the ZBX-6491, so documentation will be updated.
*UNKNOWN* results will be separated because it depends on macro LASTVALUE depends on ZBX_HISTORY_PERIOD (defines.inc.php)
I see.
In that case it should be for now somehow pointed out more clearly in the documentation.
At least that for triggers {ITEM.VALUE} is resolved in same way as {ITEM.LASTVALUE} and maybe a hint about possibly '*UNKNOWN*' values for items without history.
More clearly stated in the documentation now:
- https://www.zabbix.com/documentation/2.0/manual/appendix/macros/supported_by_location (see ITEM.VALUE entry)
Please review.
jelisejev I've made a minor correction: it can also resolve into "unknown" if the history value existed but has been deleted by the housekeeper.
zalex_ua 2.2 and 2.4 doc branches do not contain the changes.
REOPENED
martins-v Thanks, RESOLVED in:
- https://www.zabbix.com/documentation/2.2/manual/appendix/macros/supported_by_location
- https://www.zabbix.com/documentation/2.4/manual/appendix/macros/supported_by_location
zalex_ua there is suggestion to add the same sentence to ITEM.LASTVALUE macro description
martins-v I don't think we want to have duplicate entries with such details much, for the reason that it may apply elsewhere and then it would have to copied again, and again. The sentence with ITEM.VALUE remains and has been improved so that it can be understood that it relates to the latest value situation as well. RESOLVED.
asaveljevs CLOSED