Here are two aspects which are related each other.
(1)
Short history of the topic:
Fine grained control was introduced in a ZBXNEXT-1649.

In r40560 (a ZBXNEXT-2016 commit to trunk) $config['hk_history_global'] was taken into account, trends were skipped here:

// override item history setting with housekeeping settings
			if ($config['hk_history_global']) {
				$real_item['history'] = $config['hk_history'];

Later, in r40649 (a ZBX-4063 commit to trunk) there was a fix for trend:

$trendsEnabled = $config['hk_trends_global'] ? ($config['hk_trends'] > 0) : ($item['trends'] > 0);
			if (!$trendsEnabled

But both these changes were related to PNG images building only, but not to displaying possible time periods for selection on Grpah/SimpleGraph pages.

Yes, this logic is actual for graphs which don't have history/trends data in database yet, because existing data (min(clock)) have a priority when estimating possible graph range.

So now if you set an item keep history/trends settings and this item doesn't have any history/trend yet, when you open a graph with the item, you will see possible maximal period from items settings, but not globally defined.
That's wrong as for user friendly perspective, because if you open item configuration form, zabbix frontend explicitly says that the value is "Overridden by global housekeeping settings (NN days)".

(2)
Spec for the ZBXNEXT-1649 has a "Discussed topics" section, quoting:

Housekeeper parameters are not disabled in the item configuration form to allow changing them before enabling housekeeper on global level - otherwise housekeeper could remove data before the configuration is changed. The parameters must be controlled even if housekeeper is disabled for items state.

I suppose there was a logical mistake in the quote, I suppose correctly it should be like this, changed part is highlighted:

Housekeeper parameters are not disabled in the item configuration form to allow changing them before disabling housekeeper on global level - otherwise housekeeper could remove data before the configuration is changed. The parameters must be controlled even if housekeeper is disabled for items state.

but it doesn't matter already.

Note that after the initial ZBXNEXT-1649 there was the ZBXNEXT-2016 which changed the picture a lot.
Currently the quote is not actual, because internal housekeeping for history/trend tables may be enabled/disabled independently of the global "Data storage period" for the tables.

So, for better user friendly I suggest to disallow those values editing in item configuration form if they are defined on global level.
I believe it will be more consistent.

Current inconsistency may mislead when you for example perform partitioning and test then graphs building.
In such cases it's general practice to truncate history tables before partitioning and change global housekeeper settings.

Suggested patch fixes all issues I've described.
Patch based on v2.4.6