I confirm it, see attached picture.
Inconsistency should be fixed.

BUT !
Issue reporter Nicola considered in different way than I do.

We see trigger name in both widgets, but we know that trigger names uses also for events name.
Yes, widgets are different, but entries are shown is very similar style - almost the same number of columns etc.

I want to ask us all - what are shown in the widgets? events or triggers?
I'm not sure here ... but I'd say they are "triggers", because only Problem statuses are shown.

Also, using latest value ({ITEM.LASTVALUE} logic) is better in regard of performance (in 2.2 we take it from historical tables only).

So I ask to resolve it this way:
fix "Last 20 issues" widget - {ITEM.VALUE} should be expanded to latest value.

zalex_ua At the end it was fixed. On the widget the value expanded as {ITEM.VALUE}.
CLOSED.

[...] in the "Status of triggers" page we display triggers, but in "Last 20 issues" and some other places - events

(1)
Thanks Marc, in the ZBX-6698 some documentation points were improved a bit.
I hope code part will be fixed in current issue.

After the fix, documentation have to be reviewed.

zalex_ua see (3)
CLOSED

We had a meeting about this and it seems like a lot of work, because we need to consider all places this could affect, not only widget. And so we decided to leave it as is for now. That being said, this will could probably be done post 2.4 release unfortunately. Current behaviour will be documented so there is no confusion.

Related to ZBXNEXT-2768

zalex_ua Discussion will be continued there.
CLOSED.

Let's collect in this issue other cases with the same effect.
Will post as sub issues.

(2)
a) Actual for 2.2, not for 3.0:
Duplicated ZBX-8892 mentions a case that on a page tr_status.php the macro {ITEM.VALUE} in the top block header resolved the same as {ITEM.LASTVALUE}
The page has a text: EVENTS: "Last value more than 5 (222)" <- note that the EVENTS header references to a particular event, not a trigger !
I can confirm that.

Another bad point here is that being actually resolved like {ITEM.LASTVALUE} it's affected by ZBX_MAX_PERIOD (defines.inc.php), which is 1 day by default.
So if a user opens an event details which happened more than 1 day ago - he will see EVENTS: "Last value more than 5 (*UNKNOWN*) which confuses a lot !

b) Actual for 2.2, not for 3.0:
Very similar case is an event acknowledgement, where in an opened form you will see a header with wrong value ALARM ACKNOWLEDGES: Last value more than 5 (222) or a confused ALARM ACKNOWLEDGES: Last value more than 5 (*UNKNOWN*) if the event is older than 1 day.

gunarspujats RESOLVED in development branch svn://svn.zabbix.com/branches/dev/ZBX-6491 , r59171

gunarspujats Solution increased memory usage and count of SQL queries on tr_status.php page, but execution time remained the same. It correlates with configured displayed rows count in frontend - the more rows the more resources are used.

sasha Successfully tested! CLOSED

zalex_ua I can confirm the fix on pages:
Monitoring -> Dashboard,
Monitoring - > Triggers.
but it's still unfixed on:
Monitoring - > Events -> an event detail (tr_events.php),
an event acknowdelde page (acknow.php) (actual for 2.2 only)

REOPENED

zalex_ua Sasha explained that we have decided to not fix these 2 points here because they were actual for 2.2 only, and they are simply missing in 3.0 at all.

so actually this sub issue CLOSED as won't fix.
actual fix goes to Monitoring -> Dashboard, Monitoring - > Triggers pages.

Fixed in:

• pre-2.2.12 r59243
• pre-3.0.2 r59246
• pre-3.1.0 (trunk) r59247

(3) Documentation
We have to update 2.2, 3.0 and 3.2 doc branches.
https://www.zabbix.com/documentation/2.2/manual/appendix/macros/supported_by_location
https://www.zabbix.com/documentation/2.2/manual/installation/upgrade_notes_2212

Suggested changes, from

Resolved to either:
1) the latest value of the Nth item in the trigger expression, if used for displaying triggers. In this case, works the same as {ITEM.LASTVALUE}. 
2) the historical (at-the-time-of-event) value of the Nth item in the trigger expression, if used for displaying events and notifications.
In both cases it will resolve to UNKNOWN if the history value has already been deleted or has never been stored.
Supported since 1.4.3.

to:

Resolved to either:
1) the historical (at-the-time-of-event) value of the Nth item in the trigger expression, if used in context when trigger changes its status, for example for displaying events, sending notifications.
2) the latest value of the Nth item in the trigger expression, if used without context to trigger status, for example to display list of triggers in pop-up selection window. In other words, in this case, works the same as {ITEM.LASTVALUE}.
In first case it will resolve to *UNKNOWN* if the history value has already been deleted or has never been stored.
In second case, if consider frontend context only, it will resolve to *UNKNOWN* also if latest history value has been collected more than //ZBX_HISTORY_PERIOD// time ago (defined in [[:manual/web_interface/definitions|defines.inc.php]]) .
Supported since 1.4.3.

Suggestion for upgrade notes:

When displaying trigger name, previously {ITEM.VALUE} macro was resolved like {ITEM.LASTVALUE}:
- on a mouse over pop-up on "System status" widget  on "Dashboard"
- at Monitoring -> Triggers page
Now on both these places the macro will be resolved as {ITEM.VALUE}.

The details about ZBX_HISTORY_PERIOD could be added to {ITEM.LASTVALUE} macro description too.
Consider that please.
Martins, let's discuss it before modifying the doc.

martins-v Updated documentation:

• https://www.zabbix.com/documentation/2.2/manual/appendix/macros/supported_by_location
• https://www.zabbix.com/documentation/3.0/manual/appendix/macros/supported_by_location
• https://www.zabbix.com/documentation/3.2/manual/appendix/macros/supported_by_location
• https://www.zabbix.com/documentation/2.2/manual/installation/upgrade_notes_2212
• https://www.zabbix.com/documentation/3.0/manual/installation/upgrade_notes_302

RESOLVED.

zalex_ua I like it.
The only I'd strongly suggest is to keep star characters * around UNKNOWN as is, i.e. as we see that in frontend, in notifications etc.
Yes, this is a tiny technical point, but I feel that it should be preserved in documentation.

Would be good to get final Sasha's review and then can be closed.

martins-v Yes, I've added the star characters around UNKNOWN.

sasha A screen element "System status" also was affected in this issue. It must be mentioned in the Upgrade notes.

REOPENED

sasha I updated upgrade notes. RESOLVED

martins-v Reviewed, with some small changes. CLOSED

sasha Thanks a lot!

somebody actually relied on the bug in ZBX-11006.
a real-world case of https://xkcd.com/1172/