First, regarding ConsoliByte QuickBooks integration for E-junkie, they are a third-party service that we don't know much details about, but I gather they would provide their clients with a Common Notification URL to use in their E-junkie settings, so the order data for each transaction would simply get POSTed to ConsoliByte's integration script after payment completion.
Now, to address your other inquiries in order:
1) The forum thread you linked is correct. Moreover, if you just want to POST the order data to two separate scripts, you could place one script URL in the Common Notification URL and a different URL in each product's Payment Variable Information URL, or you could simply use the Common Notification URL alone to POST data to a "middleman" script that would simply resend the data to multiple other scripts. BTW, the only difference in data sets POSTed to each URL would be that the Common Notification URL does not receive the "Item Specific Non-IPN Data" variables documented on our Integration help page.
2) There is no variable explicitly stating the number of items in the cart. You could just count the number of, say, different 'quantityX' variables passed to get the number of different products regardless of item quantity, or add up the values for all 'quantityX' variables to get total item quantity.
2.1) The forum thread you linked is correct.
3) Most of the data we POST is a simple pass-thru of all the IPN data we receive from PayPal, as-is, or for non-PayPal checkouts, we convert the data we receive from the payment processor into IPN format (e.g., change variable names). Here's another good reference for those variables:
https://cms.paypal.com/us/cgi-bin/?&cmd=render-content&content_ID=developer/e_howto_html_IPNandPDTVariables
Furthermore, we add some non-IPN variables to the base IPN data set, providing data specific to our system that PayPal does not handle. Any off-the-shelf script that can handle PayPal IPN should be able to handle our Integration submissions, as long as it can handle/ignore the extra non-IPN variables we send and does not need to validate the IPN with PayPal (which would fail since we are POSTing the data, not PayPal, and we already validate IPNs we receive from PayPal anyway).
4) The 'custom' variable is NOT item-specific; there can be only one 'custom' value per order. If more than one 'custom' value is passed to the buyer's cart, only the last value passed would get included with their order. It may seem a bit confusing that this value gets passed via Add to Cart URLs when it isn't item-specific, but that's simply the only way we can pass any variables to the cart at all, since we can't presume buyers would click any View Cart buttons. If you just need to match an internal product ID at your end to the E-junkie Item Number, note that our Item Numbers are customizable, so you could easily make them exactly the same. If you need to pass another unique, hidden value per item, you can pass Variations values; see more details here:
http://www.e-junkie.com/ej/help.variants.htm
http://www.e-junkie.com/ej/help.custom.purchase-buttons.htm
(that latter page is also relevant to many of your other questions here)
5) View Cart code is unique to each E-junkie seller (references the seller's unique client ID via the URL parameter &cl=XXXXXX) but otherwise the same for all of that seller's products. You only need to make sure you include at least one complete block of View Cart code in every page that has any Add to Carts, as the View Cart code calls our 'box.js' script that manages the overlay-style cart "inside" the seller's page. You can even separate the View Cart button link (which has the unique client ID) apart from the script portion of that code (which is the same for everybody) -- e.g., putting the script portion just before the </body> to improve page-load performance, maybe have your plugin just add that to every page automatically. Do NOT use a local copy of 'box.js', as that could be problematic and would miss any new features and bugfixes we may roll out from time to time.
6) That forum thread you linked to is still accurate; at present, we have no API to send product configurations to your end nor to add/edit products from your end, independently of just using Seller Admin manually. Due to past abuse, we also do not permit automated interfacing with Seller Admin, which would soon break anyway once we release the new, DHTML-based Seller Admin we've been working on.
7) I'm not sure if you have any questions remaining on this item?
