Bitcoin-ABC has the same RPC interface as Bitcoin Core (my BitcoinMonitor application works with either daemon).  It also has the same SPV interface but uses a different transaction signing hash algorithm (the algorithm is similar to the SegWit hash algorithm)

The Bittrex symbol is BCC.

I'm a big fan of Java.  I started with Fortran on an IBM 1130, but I really like object-oriented program.  I prefer Java because it solves some of the problems with C++ and it has a rich set of libraries (both standard and third-party).  And, most of the time, you can run a program on multiple operating systems without having to generate system-dependent versions (and JNI is available for those situations where you need to directly access system functions).

You can look at my GitHub projects if you want some examples.

I brought up Bitcoin-ABC by copying the existing Bitcoin-Core folder.  But I deleted the blk*.dat files created after 7/1/2017 (just to be safe) and specified -reindex the first time that I started Bitcoin-ABC.  This essentially deleted all of the blocks/index, blocks/rev*.dat and chainstate.  It took almost 2 days for the reindex to complete (which is considerably slower than Bitcoin-Core, not sure why).

Be sure to specify a different data directory to avoid contaminating your Bitcoin directory (assuming you still want to run Bitcoin-Core).  If you are on Linux, you can use symbolic links for the early blk*.dat files to avoid copying them to the Bitcoin-ABC directory (Bitcoin-ABC will not change the existing block files).  I am running both Bitcoin-Core and Bitcoin-ABC on the same VPS by specifying port 7333 instead of 8333 for the Bitcoin-ABC daemon.  I also modified Bitcoin-ABC to accept connections only from nodes with the BitcoinCash service bit.  I also modified Bitcoin-Core to reject connections from nodes with the BitcoinCash service bit.

If you are on Windows, I found that Bitcoin-QT remembers the last data directory (it must store the information in the Windows registry).  So you need to specify -datadir for both Bitcoin-Core and Bitcoin-ABC to avoid contaminating the Bitcoin data directory.  You also need to specify -datadir for the bitcoin-cli command so that it uses the correct data directory.

No, unless you use a segwit P2SH address, transaction processing has not changed.

You can't tell by looking at the transaction output.  Segwit has a specific script format which hashes to match the P2SH value.  So only the owner of the transaction output knows that it is a segwit output (unless you can guess the owner's public key hash and generate the matching P2SH value).  Of course, once the output is spent, you can tell it is a segwith output by looking at the spending input.

There is a BIP for a native segwit address but it hasn't been implemented yet.

My first segregated witness transaction was included in block 481827

c0a4de385bfae70c77d66b7af3d09bbdfe6f1ad95e1e7537ad9a69adfb0551f8

My node is up 24/7 except for the first day of each month when I shutdown my VPS for backup and software updates.

I just closed my Coinbase account after 2 service failures.  The first one was several months ago when I couldn't withdraw funds from my USD wallet (the Coinbase dialog did not complete and customer service told me there system was perfect and wouldn't even investigate).  But the final straw was today when they suddenly insisted they needed photo id in order to sell Bitcoin (I've been a customer for 3 years).  And they would accept only webcam or smart phone camera (no file upload).  I don't have a webcam and the link they sent to my smart phone said the link was expired (I tried several times with different links).  After my previous experience, I didn't even bother contacting customer support.  So goodbye. Coinbase.

My code rejects the message since it is too short (message decode fails)

Bitcoin Core 0.13 will not accept a P2SH transaction with a witness redeem script until segwit is activated (I've tried this and the transaction is rejected).  Earlier versions of Bitcoin Core should refuse to relay the transaction because it is non-standard (you need at least two input data elements for a standard P2SH transaction and a segwit transaction has a single input element with the signature and public key in the witness data).  If you can get the spending transaction into a block, then it should be accepted by all of the nodes.

I don't know how other node software would handle this.

I need to generate P2PKH addresses for non-segwit wallets sending coins to me (the generated addresses are for my private keys).  You are correct that non-segwit wallets should handle witness transactions since they will receive them in legacy format.

For my own wallet, I've taken the approach of providing both P2PKH ('1') and P2SH-P2WPKH ('3') addresses for each private key.  The user can select either address when providing a receive address to an external site. 

When sending coins, the transaction type is determined by the outputs being spent.  A witness transaction will be created if any output is a witness output.  Otherwise, a legacy transaction is created.  The change address is then selected based on the transaction type.

This should provide interoperability with both new and old wallets.  Even if segwit is activated, that doesn't mean a particular web site will accept witness transactions.  So wallets will need to support both for some time.

There are now two transaction formats - legacy and segwit. 

A node that doesn't support segwit will receive transactions in the legacy format.  These transactions will not have the witness data, thus no signatures or public keys.  This works because the witness program allows anybody to spend the output.  A node that supports segwit will not accept a legacy transaction that attempts to spend an output using a witness program.  Thus the need to get 95% of the miners to support segwit.

A non-segwit node won't accept a segwit transaction because the format is invalid by the old rules.  So you need to get a large number of non-mining nodes to also support segwit so that the segwit transactions will be relayed across the network.

You have control over the type of transactions that you create since the initial implementation of segwit uses a P2SH address (address starts with '3') instead of a P2PKH address (address starts with '1').  Existing wallets will continue to create legacy transactions that will be accepted by both types of nodes.

I have tested this using my own wallet and Bitcoin Core 0.13.1.  Sending a segwit transaction results in a reject with the message that segwit is not active yet.  Sending a legacy transaction spending a segwit output results in a reject with the message that the witness data is missing.

SegWit needs 95% of the miners to upgrade.  You can look at the block version to see if the miner has updated (version is x'2000002' for SegWit).  So far, I'm seeing around 1 block in 10 that has the SegWit version.  So there is a long ways to go yet.  I already have a SegWit transaction in the blockchain just waiting for the support to be locked in (you can create a P2SH-P2WPKH transaction but you can't spend it yet).

Exchanges can't just unilaterally swap deposit addresses since they have no way of knowing if the customer is using a seqwit-enabled wallet.  So, even when the network supports seqwit, transactions will remain in the legacy format until people upgrade their wallets and start using the new address format.  This means businesses will need to offer both types of deposit addresses.  Users will also need to maintain both types of receive addresses until all businesses support sending funds to segwit addresses.

By the way, seqwit doesn't require HD keys.  A private key (no matter how it is generated) can have both a P2PKH address and a P2SH-P2WPKH address.  But it does mean that wallets will have to check transactions against both address formats when receiving funds.

I use firewall rules to limit concurrent connections.  But this is on Ubuntu, so it won't help you with Windows.

If you are running Windows 10, popups are disabled by default when you are duplicating the screen to multiple monitors (I have a widescreen TV as well as a computer monitor).  You can turn this off in Settings -> Notifications

With 50 connected nodes, my bitcoin server upload runs around 1.5GB/day.  However, if new nodes want historical blocks (blocks older than 7 days), this can quickly balloon to 15-20 GB/day.  Bitcoin 0.13 has an option to limit the upload size over a 24-hour period, so this can help reduce the cost.  However, SPV nodes are disconnected when this limit is reached (which you may or may not care about).

My node has been hovering around 11,000 mempool transactions lately, although right now it is at 7100.