max_temp_space enforces a limit per connection. 2 connections with a 100GB limit could easily, in aggregate, use 136 GB of temp space.

When you report the TempTablePages value above, was that at the database level or the connection level? ie, are you using db_property('tempfilepages') or connection_property('tempfilepages')?

-ca 0 probably didn't have much to do with the old case that you referenced. The old case was more about certain code paths that didn't check the limit.

The max_temp_space option defines per connection the limit on temporary usage. Your current setting indicates that a connection can use up to 100G before the error SQLSTATE_TEMP_SPACE_LIMIT is triggered. The TempTablePages value indicates there is a 86 TB temporary file ( TempTablePages * PageSize ). I prefer to query TempTablePages as the file size may not be correctly reported while the engine is running.

Is it possible that there is a very large Snapshot isolation query? The version_entries reported in sa_transactions() is a useful datapoint to determine the impact of queries using Snapshot isolation. MobiLink uses snapshots for downloads - if the download is large, the temp file is likely to grow to back the row versions on a busy server.

I would either manually query sa_performance_statistics() and sa_transactions() or create an event that periodically collects the results and stores in a table or file.

It would be also useful to enable RememberLastStatement so that you can query the what statement was being run by the connection that is consuming the temp space. To view the last statement, query CONNECTION_PROPERTY( 'LastStatement', <connnumber> ) or sa_conn_properties() to see all connections.

Just to add:

The system events GrowTemp and/or TempDiskSpace might be used here to get notified and possibly take action when the temp file grows unexpectedly.