A Trac ticket covering the issues of the current options-based implementation and the advantages of switching to a custom post type as a storage mechanism for widgets.
Widget instances are stored in options. For a multi-widget (WP_Widget) the widget instances of a given type (id_base) are stored in a serialized array of instance arrays. A widget ID is comprised of a widget's id_base followed by a number which is the array index for that widget instance. For example, the third-created Text widget would have the ID text-4 (note that multi-widget numbering starts at 2). Old single widgets do not include the numeric index after the id_base, and technically they could be stored anywhere (see #35656 for suggestion to deprecate old single widgets). Issues
There are several problems with how widgets are currently stored as options.
Scalability: For sites with a large number of widget instances, the entire collection of widgets must be unserialized with each request to access only one widget of a given type. (Note #23909 for how all widget instances get registered with every request.) For sites that use Memcached as an external object cache where cache buckets have a 1MB limit, since all widget instances of a given type are stored in a single option, sites with a huge number of widgets will overrun this limit. What's more is that widget options get registered
Interesting Trac ticket to add a "Restrict Access" option to the Media Library. Some initial feedback in AWP suggests most feel this is plugin territory because of the complexity of the server environments. Should that hinder enhancements? Or is that a REASON this should be considered in Core?
Description I've had many WordPress site owners who've e-mailed in a panic when they discover that a PDF, Word Doc, Spreadsheet, etc. they've uploaded in the Media Library has been discovered on Google with information that wasn't intended to be public. They thought that because the post or page that it was linked to was restricted, so what the media within.
The solution to this (for me) as been to move these files into a new folder, restrict it with .htaccess, and then have a PHP handler that checks for the appropriate permissions before passing the file content back to the browser.
Given I've run across this problem multiple times (with a relatively small customer base) I'd like to propose that the Media Library incorporate functionality to handle this in core.
Add a checkbox on media upload "Restrict Access to this media"
Media with that checkbox check would be uploaded into a wp-content/uploads/restricted/ tree (could still use the year/month/ subfolders).
Set .htaccess to restrict access to anything in that tree of folders.
(Haven't fully thought through this part), but create a permalink structure for accessing these resources that would be passed through the PHP engine.