Your comments

I have a feeling is has something to do with us also launching e-editions, which I think has inflated our pageviews some. (Not that I'm complaining.) Certainly, though there has been an increase in non-e-edition traffic too.
Have you tried putting a hyphen in front of your search term to act as a "not" command? I think this works in Blox.
In my experience, Blox replaces these soft returns with hard ones when it renders the text.
Personally, I'm a fan of my own site:

We make heavy use of schedules to alter the look and presentation of stories on the homepage depending on the day of the week and the time of day, trying to attract a morning crowd, hook people into deeper stories in the afternoon, and new stories at night.
I think having a field in the asset editor window for the asset that displays the permalink after you save the file would be handy as well, for quick sharing out to social media (without going through the broadcast tool every single time).
I submitted a support ticket for a feature like this to the system a while back. I think it'd be pretty useful.
I'd vote or SASS, but I really doubt TN will do CSS preprocessing on the fly. (I'd be happy to be proven wrong, though.)

I'd settle for them allowing us to use UTL inside their stylesheets to create variables and loops, though .scss files would be better.
We tried this for a while and a number of our readers reacted very poorly to it. They felt, and I eventually agreed, that their clipboards were their own business. 

However, another paper in our chain just implemented similar functionality about a week ago: I haven't heard what, if any, feedback they've had. 
Wasn't this one of my feature suggestions? ;)
You could write it in UTL if you're creating your own block pretty easily. 

foreach this.block.assets as asset;
   thumb = core_base_library_assetThumb(asset); /* or however you want to assign the thumbnail to a variable */
   if thumb.url;
       /* do stuff */

However, since there is a limit to the number of assets a block can pull in a given query, 45 or something like that, you'd be limiting the number of "viable" assets that would qualify to display in your block. 

This is a bit inefficient, of course. For example, say you told the block to pull in 20 assets per your query rules, but only 6 of them have child images. You've asked Blox to make that big query and examine all those assets from the database, but you're only using 6 of them. A bit wasteful, but not too bad.