1. Have the column hidden by default using the hidden setting of the column
2. Define the Sorting feature and set it's mode to "multi" so that the feature's modal dialog will be shown
3. Define another feature which uses indicators in header cells (Hiding, Filtering in advanced mode, Resizing or Summaries) - I'm afraid that this is the design decision that was taken in order for a feature such as Sorting's modal dialog to become available. There was _a lot_ of discussion about this and this is the final outcome, but we can still change it upon customer request though.
4. As you can see from the Multiple Sorting and Hiding Events with Modal Window sample, you can use Sorting's modal dialog to sort hidden columns without any problems.

Karl Costenbader said:

The problem is that if we call igGridSorting("sortColumn" on this hidden column, a javascript exception is thrown

This may sound like an excuse, but I mean it as an explanation: performing such an operation (sorting a column) via the API and through the UI follows slightly different logic. This is what's the matter here. The sortColumn() API method was introduced as part of the Sorting feature back in the 1st incarnation of Ignite UI (2011.1). There was no Hiding feature back then so the API method was envisioned to work with visible columns because it sort of imitates end user behavior - sorting a column visible to the end user. However, even back then the "multi" (a.k.a multiple column) sorting mode made it possible to operate on hidden columns. Yep, that was because in "multi" sorting mode, the problematic internal method that you mentioned (_clearSortStates) is never called. 

I'm not sure what the risk of applying fixes to _clearSortStates's body is, but using the "multi" sorting mode bypasses the problem immediately and unless you have something against using  (a requirement perhaps?), I strongly suggest setting it.

Martin Pavlov"] As a workaround to your issue I would suggest to sort the column in the igDataSource and then rebind the grid.

Well now, this seems a rather tough one to implement, due to the requirement of more in-depth working knowledge of the igGrid, even though it's a viable solution nonetheless.
In this case Martin relies on a presumption that the developer is aware of the igGrid's internal igDataSource object and the ability to access a jQuery widget's internals using the .data() jQuery method. However, I personally find this approach a bit tedious and I'd like to avoid it so I for now I won't attach an HTML sample showcasing it.

Karl Costenbader said:

I have found it to be very difficult to discover information for Ignite versus previous Infragistics products

How so? Can you please give us an example of such a predicament?
I'd say that the API documentation (it's autogenerated based on the code of the Ignite UI widgets) and the Developer's Guide amount to a reasonable wealth of knowledge of the product.

Karl Costenbader said:

For example, in the local help (which I often reference while disconnected), searching for a term and then selecting it takes you to the very unhelpful main navigation page as opposed to the actual term.

Oh, I agree that the Developer's Guide is a real idiot when it comes to indexing content, but that's a problem we are aware of and will resolve in the future (the help generation tools we use are somewhat dated and I'm not sure if switching over to a new set of tools will be an easy feat).

Karl Costenbader said:

In addition, the hiearchy of classes (i.e. columnSettings) is buried and difficult to understand.

 Are you referring to the Sorting feature's JS code (direct API reference to it) or the MVC wrapper for the Sorting feature's columnSettings? 
Can you also give me an example of what would you rather expect from the help docs when looking for such details? 

Karl Costenbader said:

And finally, the examples are decent for relatively trivial items, but don't go far enough in explaining more complex issues. A perfect example is the conditional row style example. Although the example shows the code, it would be MUCH more useful to explain precisely what the code does rather than having the user try to piece together what is happening from the code sample. 

I'm afraid that there is a misunderstanding on what the purpose of those samples is. They are meant to serve as simple showcases, demonstrating an operation or behavior so that a person can get a sense of the experience the end user would have when operating with one of the controls. By the way we are still moving towards the goal of making the samples even simpler.
Yes, this is a part of the policy for the official samples - if you take a look at our competitors' samples, you will see that they are following this ideology as well. 
Feel free to correct me if I'm wrong :).

Karl Costenbader said:

In otherwords, explain that each cell must have the style applied separately in order to style the entire row. It is not easy to grasp this concept from the sample code without performing an in-depth analysis of how the conditions are applied. 

We have a thing (and implementation) in mind that will hopefully become public soon that will be aligned with such requirements - more programmable samples and in-depth explanations. So far the only thing that comes close to this (and will continue to be) are our blogs where there articles with more complex samples and detailed explanations. 
NB: I strongly recommend  following Damyan Petev's blog. IMO, he writes the best samples and explanations for Ignite UI that can satisfy any developer's needs. Give the blog a read - you won't disappointed ;).

Karl Costenbader said:

One additional comment: one of the reasons that I included the source code modifications is that I see the trend continuing that started with the Ultra product line: when an issue is reported, the developers quite often rejected it or said that's the way it will be rather than taking the time to understand the problem and look for a solution.

As I pointed out in the source code, it is a very easy fix that I would hope would have been obvious to the development staff.You seem to be quite the clairvoyant, Karl :(. I saw the current status of the development issue and yes, the solution to it is to forbid (with an appropriate exception at least) calling sortColumn() (in "single" mode) of a hidden columns. I'll speak with the developer myself and I'll try to negotiate applying your suggested fix instead. I'll let you know how this goes.

Karl Costenbader said:

For the ultra product line, we had many reported issues rejected that were critical to the proper operation of our application. 

I'd like to say that fixes rely on different factors such as cross-browser compatibility, time and manpower that we can allocate for bug fixing and testing and each developer's personal scope of understanding of the code. So this is why sometimes suggested fixes have to be politely rejected in favor of updating the known limitations list. It's complicated - no better excuse I'm afraid :(.

Karl Costenbader said:

I have much higher hopes for Ignite. Our customers expect a high level of functionality, and we are relying Ignite to help us provide that functionality 

Thank you for your trust. As a person who has been testing and working with the developers of Ignite UI since it came out with the 2011.1 volume release, I'd have to say that it's a good product that's becoming even better. Yes, there are bumps and lumps along the road, but we are giving our best to make sure the quality of the controls is on par with the expectations of our customer-developers as well as their end users.

PS: Sorry for the wall of text - it's how I roll* and I hope the details here are of value to you!
Cheers!
Bobby