Here are some proposals regarding the minimum block size questions, as well as other related scalability issues.

Dynamic block size limit controller (maaku)

Re: dynamic block size limit controller (gmaxwell)

Various other gmaxwell-relayed ideas

Increasing the max block size using a soft-fork (Tier Nolan)

Elastic block cap with rollover penalties (Meni Rosenfield)

worked example https://bitcointalk.org/index.php?topic=1078521.msg11557115#msg11557115

section 6.2.3 of https://cryptonote.org/whitepaper.pdf

rollover transaction fees https://bitcointalk.org/index.php?topic=80387.0

Variable mining effort (gmaxwell)

BIP100 Soft-fork limit of 2 MB (jgarzik)

Transaction fee targeting

Difficulty target scaling

Annual 50% max block size increase

Various algorithmic adjustment proposals

(against) http://garzikrants.blogspot.com/2013/02/bitcoin-block-size-thoughts.html

Average over last 144 blocks

Extension blocks (Adam Back) (why would he burn this idea for something so trivial?)

Voting by paying to an address (note: vote censorship makes this impractical, among other reasons)

Vote by paying fees

Double the max block size at each block reward halving

Reducing the block rate instead of increasing the maximum block size (Sergio Lerner)

Decrease block interval

Increase default soft block size limit in Bitcoin Core

Consider the size of the utxo set when determining max block size (note that utxo depth cannot have consensus)

Reduce and decrease the max block size

Change the value of MAX_BLOCK_SIZE in Bitcoin Core

Problems with floating block size limits (petertodd)

Develop other ways to support high transaction volumes (gavinandresen)

Simplified payment verification

Lightning network

GHOST

Payment channels

Tree chains

fedpeg + SPV

Known missing:

- old bitcoin-development proposals

- old bitcointalk proposals

- anything unique from IRC

On a related note, the other day I found that reading all of the -wizards logs regarding sidechains only takes 2 hours. So... that's something. YMMV.