Yeah, issue summary contains 2 aspects which are different (1st closer to ZBXNEXT, 2nd is pure ZBX).
And I'd not be happy if 2nd only will be fixed as ZBX because it will not resolve a use case when this problem was discovered.

I discovered it when I had to configure a web scenario to check login to a Pootle instance http://www.zabbix.org/pootle/accounts/login/
Problem is that in 1st step I have to do a GET to get a "csrftoken" cookie value and then use this cookie value in 2nd step in POST for "csrfmiddlewaretoken" variable (additionally to "csrftoken" cookie which will be preserved).

History:
In 2.2 we have implemented step-level variables and extract regexp match in ZBXNEXT-1597
In 2.4 we have implemented only headers retrieval in ZBXNEXT-282

ZBXNEXT-1597 spec (after it recently has been fixed) explicitly says :

In case of 'regex:' prefix Zabbix will try to match this regular expression with returned HTML content (without headers)

but documentation says only:

If the value part starts with regex: then the part after it will be treated as a regular expression that will search the web page and, if found, store the match in the variable.

note how specification is much more technically detailed and correct, so doc must be updated after changes!

It's confirmed in current code:

            if (ZBX_RETRIEVE_MODE_CONTENT == httpstep.retrieve_mode)
            {
                char	*var_err_str = NULL;

                /* required pattern */
                if (NULL == err_str && '\0' != *httpstep.required && NULL == zbx_regexp_match(page.data,
                        httpstep.required, NULL))
                {
                    err_str = zbx_dsprintf(err_str, "required pattern \"%s\" was not found on %s",
                                           httpstep.required, httpstep.url);
                }

                /* variables defined in scenario */
                if (NULL == err_str && FAIL == http_process_variables(httptest,
                        httptest->httptest.variables, page.data, &var_err_str))
                {
                    char	*variables;

                    variables = string_replace(httptest->httptest.variables, "\r\n", " ");
                    err_str = zbx_dsprintf(err_str, "error in scenario variables \"%s\": %s",
                                           variables, var_err_str);

                    zbx_free(variables);
                }

                /* variables defined in a step */
                if (NULL == err_str && FAIL == http_process_variables(httptest, httpstep.variables,
                        page.data, &var_err_str))
                {
                    char	*variables;

                    variables = string_replace(httpstep.variables, "\r\n", " ");
                    err_str = zbx_dsprintf(err_str, "error in step variables \"%s\": %s",
                                           variables, var_err_str);

                    zbx_free(variables);
                }

                zbx_free(var_err_str);
            }

As we can see scenario's and step's variables will be not processed if the step has "Retrieve only headers" option enabled.
But, in frontend, while "Post" and "Required string" fields become disabled, the "Variables" field is still available to be customized!
Zabbix users is absolutely unaware that even regular variables (not =regex: like) will be just ignored for this step.
So this is pure frontend bug I mentioned as 2nd aspect.
To fix it - "Variables" field should be disabled too.

But returning to the initial use case I'd ask to resolve current issue differently - include HEADERS to BODY for web page parsing and allow to specify "Required string" in frontend too.

I don't think it can break existing zabbix installations (thinking about extended value for "Required string") as most likely already searched web page content is not included to headers.
It will be also useful for cases when checking specific headers is enough without full page retrieval.