I can’t answer every single Q you asked, as reading the Q took enough time so far ;), but I try to give you some insights about my personal experience with developing free, open source plugins.
1. Never do too much. Features are the death of every plugin. Build a basic version first and test the reaction of your users. If your plugin gets a lot of attention, you can integrate the features that are mostly requested.
2. Avoid filling every use case. You need to maintain your plugin. WP offers a new version every three month. And sometimes it’s hard to follow with all of your plugins. To make an example: A new version of the Settings API is currently discussed on Trac. When this will be finished, then there’s the chance that a lot of plugin or theme developers need to change a large portion of code and some people – like me – have even written an abstraction layer above the API. So you need to go back, rewrite your base/abstraction layer and then rework everything that calls parts of that. I promise that this is a lot of work. And even more if it’s bound tight to your code. When you start filling a lot of use cases, then you also got a lot of WP core code evolution that you need to monitor, as well as you got a lot of work keeping your code up to date.
3. Never ever try to bundle a lot of code-examples (or templates) into your plugins or themes. If you want to target developers and end users: Use your blog for documentation. Developers hate stuff like that and end-users are never satisfied (see: filling every use case).
4. Divide your code wisely into single files. Rule of thumb: One file for one part. Example: styles.php, scripts.php, taxonomies.php, cpts.php, etc. Load everything from a “mother” (factory) class and keep your stuff “pluggable”. If you need to rewrite stuff, you will find it easily. If devs are searching for something: they will find it easily. A lot of well named files, don’t harm you.
5. If you got a list of basic styles (classes), leave it up to the user. Chances are simply too high, that styles from the theme or other plugins will intercept your definitions (no matter how much specifity you throw in). Just try to explain it somewhere with as less text as possible.
6. Love your plugin. But let go if you’re bored. 🙂
Now – in short words – something about your plugin idea in detail:
A. Template files are bad. As I said: Document it on your blog, offer example mark-up and styles there. Your blog will profit (and you as well if you got ads).
B. Shortcodes are kool. They don’t harm anybody if the plugin is gone (in most cases) and could be later extend/evolved to TinyMCE buttons (which people love).
C. Make it clear that your plugin needs another plugin. Question this and add a note to admin_notices (via register_activation_hook) if the other plugin doesn’t exits (link it in this case) or isn’t activated (you could do this for the user on activation). Also note that this plugin comes from a trusted source and will be maintained for the next years.
Note: Nothing I wrote is anything more than my personal opinion, which reflects my experience.