I don't understand why you wouldn't want to have the _build files under version control. That doesn't mean they'll be part of the package, but it's nice to have access to previous versions of them.
You say you put files under assets/components/proctname, but what about the files needed for the core? Or _build? To get the structure correct for the Extra, you will either way have to init the repo in the modx base directory.
No, definitely not. I have about 50 extra projects under assets/mycomponents/. They all work fine there and the packages work fine when installed. Many of them can also be run in my editor (PhpStorm).
This makes them use the local files during development and the installed files for users. It's used for all class, CSS, and JS files:
require_once $modx->getOption('nf.core_path', null, $modx->getOption('core_path') . 'components/notify/') . 'model/notify/notify.class.php';
This makes them work in the editor:
if (! defined('MODX_CORE_PATH')) {
require_once 'c:/xampp/htdocs/addons/assets/mycomponents/instantiatemodx/instantiatemodx.php';
}
It can be removed before distribution, though it's harmless inside MODX.
If your project is at all complex, I urge you to try MyComponent. Its help with lexicon strings alone is worth the effort. It will build stubs for all your files complete with custom author and copyright notice, PhpDoc blocks, and a customizable license statement.
MC will let you make changes in MODX and export them to your files, and vice versa. It will also let you use static files during development and turn that setting off automatically when the package is built.
MC comes with a universal build.transport.php file that works as is for at least 95% of my extras (it also automatically handles subpackages, validators, and resolvers).
At MODXpo, I created a complete, distributable package with a resource, a snippet, a Tpl chunk, snippet properties, and lexicon strings. It took less than 20 minutes, including writing the code.