Revision data is accessible for GDL objects via global variables assigned specifically for this function.
These globals are separated into issue and change related pairs, and the issue and change data can be linked by the Revision ID, which is present in all arrays.

Issue related pair

GLOB_ISSUE_SCHEME[2][numIssueData] (string type array):
It collects the header titles set in the Issue scheme settings palette, has 2 fix rows and handles indefinite number of columns (numIssueData).
It contains valid data in every context/view-type. The firs line in the array is the title string of the header, the 2. line contains the related static unique GUID, both are stored in string format.
New data (column) can be added in the Issue scheme settings palette and it generates a new ID as well for the new title.
The ID does not change until the data is deleted from the scheme, but the name string can be changed, renamed on demand. The first 5 data are wired, those cannot be deleted by the user. So the array is never empty:
“Revision ID”, “Issue ID”, “Issue Name”, “Issue Date”, “Issued by” and matching GUIDs are always present:

This list can be modified/extended by the user.

The next few fields are coming from the Layout Settings/Layout Info list:

LAYOUT_REVISION_HISTORY[ ][numIssueData] (string type array):
it contains the issue data according to the GLOB_ISSUE_SCHEME titles, as set in the New Issue palette.
Can handle indefinite number of rows and columns (but column number always matches GLOB_ISSUE_SCHEME, numIssueData).
The data may be quite different regarding each Layout, and available only in Layout context/view-type (therefore this global is empty in every other context and view-type).
Each row contains the revision data of the current layout only (had anything changed since the latest issue, is there a revision of the layout in the current issue, etc.).
Each revision occupies one row only. The data is arranged to match the title order of GLOB_ISSUE_SCHEME, so the first few are fixed in the same manner. This array contains the Layout Settings/Layout Info data as well set in each individual Layout’s settings, followed by any custom user set fields’ data.

Change related pair

GLOB_CHANGE_SCHEME[2][numChangeData] (string type array):
collects title/header data from Change manager, set in the scheme editor palette.
Has fix 2 rows and handles indefinite number of columns (numChangeData). It is filled in every context/view-type in the same manner as GLOB_ISSUE_SCHEME, containing titles and matched GUIDs.
First 5 column titles are fixed:
“Revision ID”, “Change ID”, “Change Name”, “Last Modified Date”, “Last Modified by”, the list can be customized in Change Scheme settings.
Same rename-delete logic works here as in GLOB_ISSUE_SCHEME: the name can change, but the GUID stays fix until deleted completely.

LAYOUT_CHANGE_HISTORY[ ][numChangeData] (string type array):
data pair of the GLOB_CHANGE_SCHEME, with matching column logic, while every row contains data related to one change.
Only valid in Layout context/view-type.
Changes belonging to a specific revision can be identified by the data in the first column, which contains the ID of the revision the change occurred in.

  The downloadable example object can display the values of the above global variables of each individual layout page.
Make sure you add some changes and issues to your plan before testing it.

The global variables, as any other regular GDL variables, can be accessed by using their names as handles in the script:

for _i=1 to vardim1(GLOB_ISSUE_SCHEME)
	for _j=1 to vardim2(GLOB_ISSUE_SCHEME)
		text2 0,0, GLOB_ISSUE_SCHEME[_i][_j]
		add2 0, -0.01
	next j_
	add2 0, -0.01
next _i

All four of them can be used in Parameter script without restrictions.

There is a fifth revision global:
LAYOUT_CURRENTREVISION_OPEN (boolean): 0 – the issue is closed, 1 – the issue is still under construction.
This can be used to add a “Work in progress” watermark to your custom revision data table.

For more, check out the Revision History objects of the current ARCHICAD library.