Index: doc/proposals/autogen.md
===================================================================
--- doc/proposals/autogen.md	(revision a86326156612cd0c81a646dc9b1f0b110c2eacf5)
+++ doc/proposals/autogen.md	(revision 00aa122cd8a610fd71bc1afaa8e4910742e18a62)
@@ -100,4 +100,25 @@
 The main reason to manually remove functions is to enforce a behaviour based interface for a type, as opposed to a data based one. To enforce that new interface, this would have to interact with visibility.
 
+### Automatic Remove Hides Everything
+As soon as you declare a custom constructor, _all_ autogenerated constructors become inaccessible. Often, this behaviour is good, and it agrees with C++. But the desire dual to "manually remove" exists: "manually keep." Furthermore, there is a use case for invoking an automatically provided constructor as a helper, when implementing a custom constructor.
+
+	struct S {
+	    int i;
+	    int & j;
+	};
+	void ?{}( S & s, int & w ) {
+	    // Unique best alternative includes deleted identifier in:
+	    s{ 3, w };
+	    // intended meaning / workaround:
+	    // s.i = 3; &s.j = &w;
+	}
+
+This use case should be considered also, along with visibility. A private helper constructor should be usable in the implementation of a public value-add constructor. The private helper being an autogen is one such arrangement.
+
+Users should have the option to adopt the idiom: All constructors funnel into the most private, all-member constructor.
+
+### Removed Functions Linger
+Even if a function is made CFA-uncallable, it still shows in the emitted C code (`cfa -CFA`). An uncallable function shows identically to a callable function, with no indication of, "This declaration has been deleted," or, "Here is a redaction of X." This quirk reduces the utility of inspecting -CFA to answer, "What constructors would be available to me?" or, "What's the net effect of the constructor declarations and deletions that I've given?"
+
 ## Other Problems & Requested Features