Temp solution

For those who might run into this issue here is solution for this kind of situation:

var initialgetUrlParam = getUrlParam;
getUrlParam = function(){
    if(arguments[0] == 'view'){
        return 'lp';
    }else{
        return initialgetUrlParam.apply(document, arguments);
    }
}

And may be

var initialGetElementById = document.getElementById;
document.getElementById = function(){
    if(arguments[0] == 'jform_title'){
        return initialGetElementById.apply(document, ['jform_c_title']);
    }else{
        return initialGetElementById.apply(document, arguments);
    }
}

If you have c_title for some reason instead of title.
But remember: having anything_title instead of title is a BAD HABBIT

IMHO, you're right. It's not correct to use the url parameters to determine the asset key.

unless i'm mistaken, it should use the typeAlias property of the component item model.

BTW in 3.6.0 there is no /media/system/js/permissions.min.js file. The files are:

• https://github.com/joomla/joomla-cms/blob/staging/media/system/js/permissions.js
• https://github.com/joomla/joomla-cms/blob/staging/media/system/js/permissions-uncompressed.js

1 . For requirement in JS to have 'jform_title', for forms that do not have, i am adding a hidden empty field with id:

jform_title

• you can take time to make a PR i promise to test it

2 . For the view naming issue, i am manipulating the posted data ... when needed ... to work around it, i don't know if you would like to make a PR for this too, i will test too

3 . Finally, about:

and new asset record added to table with parent_id = 0

if 2 assets with parent_id = 0, are created (due to software bugs), then ACL no longer works

• there should be a check somewhere if the above happens for any reason , and e.g. delete all extra assets with parent_id = 0 and wrong name, if you make a PR for this, i will test too

For requirement in JS to have 'jform_title', i am adding a hidden empty field:

Why? Why is core creating hardcoded requirements to explicit form fields being present? Why are our JavaScript APIs not open to have these things customized as needed? We're creating a lot more JavaScript based integrations in core and we're making a lot of the same mistakes as exist with our PHP code, creating hardcoded requirements on certain conventions without introducing mechanisms to change those hardcoded values for scenarios that they don't exist in.

Thank you for raising this issue.

Joomla 3 is now in security only mode with no further bug fixes or new features.

As this issue doesn't relate to Joomla 4 it will now been closed.

If we are mistaken and this does apply to Joomla 4 please open a new issue (and reference this one if you wish) with updated details for testing in Joomla 4
cc @zero-24