chore: Please move this refactoring to a dedicated [REF] commit before the other commits of this PR.
This is because commits should affect only one module as much as possible, see:

Avoid commits which simultaneously impact lots of modules.
Try to split into different commits where impacted modules are different.
This is helpful if we need to revert changes on a module separately.

(from https://github.com/OCA/odoo-community.org/blob/master/website/Contribution/CONTRIBUTING.rst#71commit-message)

Seperate commit created for web_company_color module.

👍

question: Why do we have to scss_create_or_update_attachment every time any module is installed? Based on the README, maybe this has to be done only when web_responsive is updated.

Same concern also for the uninstall method below.

Agree the approach leads to calling of "scss_create_or_update_attachment()" method every time each module is installed, which was missed by me to address in 14.0 when implemented.

Objective: When a module adds new elements to the SCSS template, the added modules is customized only when the method scss_create_or_update_attachment() is invoked. The same needs to be taken care when module is uninstalled (to remove elements introduced by module)

This is achieved using hooks(post install and uninstall) in web_company_color.

Approaches:

1. Using same hooks in every module(web_responsive_company_color, other modules which are introduced based on this bridge module) becomes duplication of code and in order to remove redundant code, used ir_module button_install() in 14.0 and adpated for 16.0 here. - This definitely have the flaw
2. Tried to use JS Component to call the scss_create_or_update_attachment() whenever module gets installed/uninstalled based on rpc query - Since component is not used anywhere in templates as such, component is not getting loaded.
3. Add an eventListener to a bus in this bridge module and send an event from backend using "bus.bus" module whenever install/uninstall of module happens so that we can call "scss_create_or_update_attachment()" for customization to take effect from bridge module and its dependencies. - I have not tried implementation of this approach as I am not sure it's a right way.

Your inputs would be helpful. Please let me know your views.

Thanks for clarifying the issue and proposing a few approaches.
In my opinion you cannot ask the user to remember to reinstall the module every time a string is changed, and calling this method every time any module is installed is overkill because most modules won't need it.
So I'd go with the installation hooks (that is web_company_color's approach).

I appreciate very much your concern about code duplication but that is why functions/methods exist!
We are not duplicating the logic: all the logic has already been carefully extracted in the method res.company.scss_create_or_update_attachment, then this method is called wherever it is needed (in hooks of modules that edit the SCSS).

I have updated using hooks as discussed earlier and removed using "ir.module" logic based on "button_install and button_uninstall".

question: Do you mean when someone modifies the string returned by method res.company._get_scss_template?

Please give more details about this issue because it's very strange that the module has to be updated when something changes: if the failing use-case is clear maybe we can fix it before the PR is merged.

Given details of the issue faced in the above comment.

As method _get_scss_template() is invoked only during post_init_hook and uninstall_hook, hence when an new element is inserted inside method get_scss_template() to customize styling, one need to take care of migrartion in which post_init_hook() needs to be invoked, which makes customization to take effect. So, removed comment mentioned earlier in the usage. Also, I would like to know whether this information should be updated as part of documentation.

Please let me know your thoughts.

thought: This context value is not used in the module, so I don't think it should be in this module, but it does no harm and could be useful for downstream methods to know that we are uninstalling.

It would be better if downstream modules that need it could find another way to recognize this situation, like:

    def button_immediate_uninstall(self):
        return super(self.with_context(...), ClassName).button_immediate_uninstall()

Once approach is concluded, we try to address it if required

Not using ir.module with this implementation. Hence, omitted this comment.

chore: Usually you only add yourself as a contributor when you work on a module, but I think that you worked on this from the beginning so this is fine, just don't remove the other authors.

question: I can't find this image in https://github.com/OCA/web/tree/9bfd8c348ad94233606aa04954bdb7d21b640a8e/web_responsive/static/img, how is it being loaded?

Updated with correct url path: /web_responsive/static/src/img/home-menu-bg-overlay.svg