For unmanaged packages, any conflicts will either prevent the installation from occurring, or rename the incoming elements so they no longer conflict. This is generally a Bad Thing, especially if you're in the habit of using Strings instead of SObjectType and SObjectField tokens. You will end up with duplicates, assuming the install is allowed to succeed. Such packages are not upgradable, either.
So, if you're serious about servicing your clients, and especially if you want to allow them to upgrade to newer versions without conflicts/errors, you'll want to use a managed package. In that design, each package has a "namespace" that uniquely identifies the fields, objects, classes, triggers, layouts, and so on that are used in the package, preventing any possibility of conflicting with anything else a client may have manually created or installed from another package.
There are some limitations, such as what you can delete or modify, once the package is managed, but as long as you read the ISVForce guide beforehand, understand the implications, and abide by the rules, it should be entirely possible to remove many of the headaches that you have by using unmanaged packages. Also, managed packages obscure your code, protecting your intellectual property, and also allows you to turn off client licenses in the event that your app is no longer being paid for, etc (e.g. they can't steal your service that you were charging monthly/yearly for).
So, read the ISVForce guide, make your managed package, remember to pass a security review so you can get the Force.com Certified logo, and you'll be good to go (logo is optional, but highly recommended for your brand).