Earlier quoted context omitted.
In Linux it's easier to install something that in Windows. Sure, as long as it's in your distro, and it's the version you want, and you haven't installed anything else that might interact with it from another source. But if any of those three statements is not true, best to start praying to whatever deities you believe in for one of them to help you, because chances are no-one else is going to. The thing that really…
Because often applications need to be able to read and write files that have been created by other programs. Some programs also have features which add functionality to other applications. Sometimes this can be useful , in cases such as lastpass and dropbox but other times they can be bad in cases such as spyware.
I challenge your position that this "often" happens. Stop and look at the different kinds of data you work with and the applications you use to work with it. I bet you'll find a lot of your applications only work with their own formats and/or a fairly small number of other common ones such as standard text/graphic file formats. Even if your applications could theoretically work with many different common formats, say a graphics editor that speaks 30 different file formats or a generic text editor that can edit many different kinds of source file, I bet in practice you only use a handful of those graphic formats or use a few different kinds of text file on any given system. Almost nothing, except for system/comms software that deals with files as black boxes without caring what kind of data they hold, needs arbitrary access to any file type.
Would it really be so hard to established a systematic model for these requirements and then actively enforce it, so applications had to disclose exactly which types of data they wanted to access? This could be shown as part of a standardised installation process built into the OS, or at least summarised there and the full details made available to the user (and permissions configurable by that user) from a separate UI later.
Keep in mind that to some extent this is already done. On Windows, for example, there is already a database of recognised file types and a database of associations between applications and those types. It's used when you double click on something to open it, or to decide which options to offer when you select "Open with..." on the menu. It's just only used for convenience at present, not enforced as a part of the security model. And there are already standardised install/uninstall UIs on most platforms, but again they aren't enforced so that applications have to play nicely and the OS can forcibly uninstall them in their entirety on user request.
Some programs also have features which add functionality to other applications.
Sure, so let them announce explicitly when they are installed that they want permission to interoperate with x, y and z other packages, and let the user say no.
And make it a pull model rather than a push one: software being installed can grant permission for other software to depend on it, but not change the other software itself. That way, the main software is always in control, not the plug-ins. This is just a smaller-scale version of the principle that the OS should always be in charge of the overall system and should be able to install/uninstall/restrict/authorise any other software according to the user's wishes, and the other software doesn't get a vote.